Subject: RE: Validation policy in DPV/DPD rqmts

From: [email-masked]
Date: Thu, 28 Feb 2002 01:29:26 +0000

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

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

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

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

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

That at any rate is my $0.02.  

Khaja

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

---

From: "todd glassey" <[email-masked]>
Date: Thu, 28 Feb 2002 06:08:13 -0800

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

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

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

    1)    making decisions regarding identity and rights of the participants

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

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

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

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

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

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

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

Todd Glassey

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

> business and legal elements as well.

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

> For example a
> typically not saying merely that.

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

>  It is also saying

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

> Indeed I dont' believe there should be something like a

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Feb 2002 10:20:23 -0500

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

Todd,

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

Steve

---

From: "todd glassey" <[email-masked]>
Date: Thu, 28 Feb 2002 08:28:08 -0800

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

> complex); the approach we are pursuing in PKIX is consistent with

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

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

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

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 28 Feb 2002 11:04:42 -0800

Todd,

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

Mike

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Feb 2002 15:00:26 -0500

Todd,

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

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

Steve

---

From: "todd glassey" <[email-masked]>
Date: Thu, 28 Feb 2002 13:24:06 -0800

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

Todd

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

> >>  >This is yet another example with the problems of this WG - The fact
that
> >a
> >>  >Tim and Steve any retort since you are responsible for what this
group
> >does?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Feb 2002 16:37:07 -0500

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

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

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

Steve

---

From: "todd glassey" <[email-masked]>
Date: Thu, 28 Feb 2002 14:56:34 -0800

Steve

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

> I've chaired PKIX since it's inception.

My point exactly

> For comparison, the duration
> has chaired CAT.

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

>  also chaired the PEM WG prior to PKIX, chaired

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

>
> There are no term limits for WG chairs.

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

> If you want to suggest term

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 28 Feb 2002 15:38:02 -0800

At 2:56 PM -0800 2/28/02, todd glassey wrote:
>inside this WG...

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

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

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 28 Feb 2002 15:38:02 -0800
To: "todd glassey" <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Changing the IETF (was Re: Validation policy in DPV/DPD rqmts)
Sender: [email-masked]

At 2:56 PM -0800 2/28/02, todd glassey wrote:
>inside this WG...

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

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

--Paul Hoffman, Director
--Internet Mail Consortium

From: "todd glassey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "LISTS - IETF-PKIX" <[email-masked]>
Cc: "Al Arsenault" <[email-masked]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 14:56:34 -0800
Sender: [email-masked]

Steve

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

My point exactly

> Steve

From: "Michael Myers" <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 14:14:17 -0800
Importance: Normal
Sender: [email-masked]

Russ,

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

Mike

Michael Myers
t: +415.819.1362

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

From: "Housley, Russ" <[email-masked]>
To: Michael Myers <[email-masked]>
Cc: [email-masked]
Date: Thu, 28 Feb 2002 15:38:59 -0500
Subject: RE: Validation policy in DPV/DPD rqmts
Sender: [email-masked]

Mike:

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

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

Russ

Date: Thu, 28 Feb 2002 16:37:07 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Validation policy in DPV/DPD rqmts
Cc: <[email-masked]>
Sender: [email-masked]

Steve

From: "todd glassey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 13:24:06 -0800
Sender: [email-masked]

Todd

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

that
group
> down. Absent that, we will continue to do out best, despite your

Date: Thu, 28 Feb 2002 15:00:26 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Validation policy in DPV/DPD rqmts
Cc: <[email-masked]>
Sender: [email-masked]

Todd,

Steve

From: "Michael Myers" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 11:10:10 -0800
Importance: Normal
Sender: [email-masked]

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

Denis,

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

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

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

Is that possible?

Mike

From: "Michael Myers" <[email-masked]>
To: "todd glassey" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 11:04:42 -0800
Importance: Normal
Sender: [email-masked]

Todd,

Mike

From: "Michael Myers" <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 10:22:04 -0800
Importance: Normal
Sender: [email-masked]

Russ, Denis:

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

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

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

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

Mike

Date: Thu, 28 Feb 2002 18:07:41 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Ambarish Malpani <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on the DPV-DPD req doc
Sender: [email-masked]

Ambarish,

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

> Hi Denis, Russ,

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

[COMMENT 10]

1. Section 4 2nd paragraph

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

[Answer 10]

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

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

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

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

[COMMENT 11]

2. Section 4 3rd paragraph

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

[Answer 11]

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

[COMMENT 12]

3. Section 4 6th paragraph

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

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

[Answer 12]

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

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

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

[COMMENT 13]

3. Section 4 8th paragraph

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

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

[Answer 13]

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

[COMMENT 14]

5. Section 4 return states

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

[Answer 14]

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

[COMMENT 15]

4. Section 4 2nd last paragraph

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

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

[Answer 15]

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

[COMMENT 16]

7. Section 7.1 7th para onwards

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

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

[COMMENT 17]

8. Section 8.1.4

More cautionary period stuff

[Answer 17]

Same.

[COMMENT 18]

9. Section 9

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

[Answer 18]

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

Denis

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

Date: Thu, 28 Feb 2002 18:01:37 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Validation policy in DPV/DPD rqmts
Sender: [email-masked]

Michael,

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

Some text is already there. 

Take a look at section 7.1. Validation Policy

Denis
 
> w: http://www.traceroutesecurity.com

Date: Thu, 28 Feb 2002 16:54:24 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Denis Pinkas <[email-masked]>
CC: Peter Sylvester <[email-masked]>, Petra Barzin <[email-masked]>, [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Sender: [email-masked]

Denis,

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

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

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Peter Sylvester <[email-masked]>
Date: Thu, 28 Feb 2002 17:44:02 +0100 (MET)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Cc: [email-masked]
Sender: [email-masked]

Thanks for the response. 

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

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

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

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

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

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

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

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

> No change is necessary.
I Disagree.

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

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

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

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

Another example is in relaying as follows: 

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

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

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

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

There are requirements for relaying etc. 

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

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

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

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

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

Peter

From: "todd glassey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 08:28:08 -0800
Sender: [email-masked]

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

> Steve

From: "Michael Myers" <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 07:48:58 -0800
Importance: Normal
Sender: [email-masked]

Steve, Russ:

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

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

Mike

Michael Myers
t: +415.819.1362

Date: Thu, 28 Feb 2002 16:37:50 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Sylvester <[email-masked]>, Petra Barzin <[email-masked]>
CC: [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Sender: [email-masked]

Petra and Peter,

Please find below responses to your comments.

COMMENTS FROM PETRA BARZIN

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

[COMMENT 1]

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

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

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

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

[COMMENT 2]

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

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

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

[COMMENT 3]

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

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

[COMMENT 4]

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

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

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

COMMENTS FROM PETER SYLVESTER

There are some comments for DPV that have been ignored.

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

- Security requirements

[COMMENT 5]

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

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

[COMMENT 6]

- a method to ensure confidentiality of the transport.

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

[COMMENT 7]

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

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

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

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

[COMMENT 8]

One may resume the relaying requirements into one:

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

- Relaying requirements:

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

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

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

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

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

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

[COMMENT 9]

- Requirements for incomplete answers:

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

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

Regards,

Denis

Date: Thu, 28 Feb 2002 10:20:23 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Validation policy in DPV/DPD rqmts
Cc: <[email-masked]>
Sender: [email-masked]

Todd,

Steve

Date: Thu, 28 Feb 2002 10:04:08 -0500
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Cc: <[email-masked]>
Sender: [email-masked]

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

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

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

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

Steve

From: "Housley, Russ" <[email-masked]>
To: Michael Myers <[email-masked]>
Cc: [email-masked]
Date: Thu, 28 Feb 2002 09:24:46 -0500
Subject: RE: Validation policy in DPV/DPD rqmts
Sender: [email-masked]

Mike:

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

Russ

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

From: "Fillingham,  David W." <[email-masked]>
To: "PKIX (E-mail)" <[email-masked]>, "Federal PKI TWG (E-mail)" <[email-masked]>, "TWG-BWG Mail List (E-mail)" <[email-masked]>, "DOD BCA Integration (E-mail) (E-mail)" <[email-masked]>, "Bridge CA Mail List (E-mail)" <[email-masked]>
Cc: "Dunshee, Diane M." <[email-masked]>, "Essman, Kristine R." <[email-masked]>, "Redgraves, Michael R." <[email-masked]>, "Lake, Barry A." <[email-masked]>, "John Pawling (E-mail)" <[email-masked]>
Subject: Free Public Key Enabled Application Test Suite Available
Date: Thu, 28 Feb 2002 09:19:04 -0500
Sender: [email-masked]

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

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

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

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

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

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

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

* certificate revocation using Certificate Revocation Lists (CRL);

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

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

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

ldap://bcatest.atl.getronicsgov.com

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

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

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

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

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

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

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

to successfully validate the BITS test data.

The BCA Demonstration Phase II final report is available from:

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

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

From: "todd glassey" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 06:08:13 -0800
Sender: [email-masked]

hey all -

Todd Glassey

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

> > w: http://www.traceroutesecurity.com

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
Date: Thu, 28 Feb 2002 07:08:13 -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		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
	Pages		: 20
	Date		: 27-Feb-02
	
This document defines two private X.509 v3 certificate extensions.
The first binds a list of IP address blocks, or prefixes, to the
subject of a certificate.  The second binds a list of Autonomous
System Identifiers to the subject of a certificate.  These extensions
may be used to convey the authorization of the subject to use the IP
addresses and Autonomous System identifiers contained in the
extensions.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 28 Feb 2002 11:38:35 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Michael Myers <[email-masked]>
CC: "Housley, Russ" <[email-masked]>, [email-masked]
Subject: Re: Validation policy in DPV/DPD rqmts
Sender: [email-masked]

Mike,

Russ gave you the right answer (copied below).

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

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

(...)

> >production of running code.  

Since you confessed, you are forgiven. :-)

There is a difference between :

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

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

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

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

I hope we can now close this issue.

Denis

From: [email-masked]
To: "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 01:29:26 +0000
Sender: [email-masked]

DEFAULT

Michael, 

Khaja

> w: http://www.traceroutesecurity.com

From: "Michael Myers" <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Wed, 27 Feb 2002 16:37:47 -0800
Importance: Normal
Sender: [email-masked]

Russ,

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

Mike

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 2:31 PM
> To: Michael Myers
> Cc: [email-masked]
> Mike:
> I think that each server will have a default, but I
> do not think that each server will have the same
> policy as the default.

I agree.  Probably so.

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

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

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

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

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

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

Mike

Content-return: allowed
Date: Wed, 27 Feb 2002 16:15:00 -0800
From: Ambarish Malpani <[email-masked]>
Subject: Comments on the DPV-DPD req doc
To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

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

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

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

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

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

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

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

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

8. Section 8.1.4
    More cautionary period stuff

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

Sorry for the long mail.

Regards,
Ambarish

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

From: "Housley, Russ" <[email-masked]>
To: Michael Myers <[email-masked]>
Cc: [email-masked]
Date: Wed, 27 Feb 2002 17:31:05 -0500
Subject: RE: Validation policy in DPV/DPD rqmts
Sender: [email-masked]

Mike:

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

Russ

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

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Wed, 27 Feb 2002 12:02:05 -0800
Importance: Normal
Sender: [email-masked]

Denis,

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

Mike

Michael Myers
t: +415.819.1362

Date: Wed, 27 Feb 2002 14:33:34 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Validation policy in DPV/DPD rqmts
Sender: [email-masked]

Michael,

This is my answer on the second thread.

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

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

The text also says:

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

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

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

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

This is unrelated.

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

Once again unrelated.

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

Once again unrelated.

Denis

> w: http://www.traceroutesecurity.com

Date: Wed, 27 Feb 2002 14:19:17 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Sender: [email-masked]

Michael,

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

Yes, indeed it is.

> If so, a few more thoughts:

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

Denis

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

From: "Michael Myers" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Tue, 26 Feb 2002 08:30:48 -0800
Importance: Normal
Sender: [email-masked]

Denis,

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

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

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

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

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

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

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

Mike

Michael Myers
t: +415.819.1362

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

From: Peter Sylvester <[email-masked]>
Date: Tue, 26 Feb 2002 17:25:08 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

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

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

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

Do I agree with Mike by saying the following?

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

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

regards
Peter

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

Date: Tue, 26 Feb 2002 13:48:34 +0100
From: Juergen Brauckmann <[email-masked]>
Organization: TC TrustCenter AG
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Hi Peter.

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

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

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

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

Regards,
    Juergen

Date: Tue, 26 Feb 2002 12:03:52 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Sender: [email-masked]

Peter,

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

> Does 3 indicate a temporary or permanent error?

Good question !

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

However, you don't propose a solution.

One way to fix the problem would be to say:

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

In fact what is important for an application is:

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

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

Denis

From: Peter Sylvester <[email-masked]>
Date: Tue, 26 Feb 2002 11:49:05 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Cc: [email-masked]
Sender: [email-masked]

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

Does 3 indicate a temporary or permanent error?

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

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

Date: Tue, 26 Feb 2002 10:50:47 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Sender: [email-masked]

Michael,

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

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

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

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

So I would propose the following fix:

The DPV response MAY indicate one of three status alternatives:

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

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

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

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

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

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

Date: Mon, 25 Feb 2002 23:14:58 +0100
From: Petra Barzin <[email-masked]>
To: Michael Myers <[email-masked]>
Cc: [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Sender: [email-masked]

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

Petra

Michael Myers schrieb:

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

content-class: urn:content-classes:message
Subject: v1.3 R8 Enhanced SNACC Freeware Now Available
Date: Mon, 25 Feb 2002 15:29:03 -0500
From: "Pawling, John" <[email-masked]>
To: "ietf-pkix@imc. org (E-mail)" <[email-masked]>, "SMIME WG (E-mail)" <[email-masked]>
Sender: [email-masked]

All,

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

large ASN.1 INTEGERs, and improve memory usage.    

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Housley, Russ" <[email-masked]>
To: Hiro <[email-masked]>
Cc: [email-masked]
Date: Mon, 25 Feb 2002 13:58:10 -0500
Subject: Re: not required to support IDP?
Sender: [email-masked]

Hiro:

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

Russ

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

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

From: Peter Sylvester <[email-masked]>
Date: Mon, 25 Feb 2002 19:26:54 +0100 (MET)
To: [email-masked]
Subject: Re: agenda topics, WG last call for DPV requirements
Sender: [email-masked]

There are some comments for DPV that have been ignored.

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

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

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

One may resume the relaying requirements into one: 

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

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

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

From: "Michael Myers" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Mon, 25 Feb 2002 09:18:50 -0800
Importance: Normal
Sender: [email-masked]

Denis,

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

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

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

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

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

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

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

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

Mike

Michael Myers
t: +415.819.1362

Date: Mon, 25 Feb 2002 15:31:32 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
Sender: [email-masked]

Michael,

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

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

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

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

Denis

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

From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "Khaja E. Ahmed" <[email-masked]>, "Michael Myers" <[email-masked]>, <[email-masked]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Mon, 25 Feb 2002 10:50:41 -0300
Importance: High
Sender: [email-masked]

I agree with eliminating this state.

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

If not, I would prefer to separate this state.

Roberto

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

From: "Housley, Russ" <[email-masked]>
To: Roberto Opazo Gazmuri <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 19 Feb 2002 10:42:03 -0500
Subject: RE: Comment on RFC 2459
Sender: [email-masked]

Roberto:

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

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

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

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

From: "Khaja E. Ahmed" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Fri, 22 Feb 2002 23:27:20 -0800
Importance: Normal
Sender: [email-masked]

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

Khaja

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Fri, 22 Feb 2002 19:29:55 -0800
Importance: Normal
Sender: [email-masked]

Russ, Denis:

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

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

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

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

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

Mike

Date: Thu, 21 Feb 2002 12:32:48 +0100
From: Petra Barzin <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: agenda topics, WG last call for DPV requirements
Sender: [email-masked]

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

Content-return: allowed
Date: Wed, 20 Feb 2002 15:21:57 -0800
From: Peter Williams <[email-masked]>
Subject: RE: not required to support IDP?
To: "'David A. Cooper'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Summary

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

-------

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

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

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

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

Simon,

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

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

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

Dave

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

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

Date: Wed, 20 Feb 2002 17:11:53 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: RE: not required to support IDP?
Sender: [email-masked]

Simon,

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

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

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

Dave

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

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

Date: Wed, 20 Feb 2002 22:55:00 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
Cc: [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

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

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

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

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

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

Ciao, Michael.

Date: Wed, 20 Feb 2002 22:55:23 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
Cc: [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

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

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

Ciao, Michael.

content-class: urn:content-classes:message
Subject: RE: not required to support IDP?
Date: Wed, 20 Feb 2002 16:53:09 +0100
From: "Simon Tardell" <[email-masked]>
To: "Hiro" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Hiro,

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

Simon

Simon Tardell, Software Architect, SmartTrust
voice +46 8 6853174, fax +46 8 6856530
cell +46 70 3198319, [email-masked]

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

Date: Wed, 20 Feb 2002 22:57:05 +0900
To: [email-masked]
From: Hiro <[email-masked]>
Subject: not required to support IDP?
Sender: [email-masked]

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

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

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

Does anyone answer for this question?

Regard,

--
Hiro
[email-masked]

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "LISTS - IETF-PKIX" <[email-masked]>
Subject: Re: Policy requirements for Time-Stamping Authorities
Date: Tue, 19 Feb 2002 07:10:59 -0800
Sender: [email-masked]

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

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

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

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

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

Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Mon, 18 Feb 2002 18:02:26 -0500
Sender: [email-masked]

      Peter:

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

            Tom Gindin

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

Sent by:    [email-masked]

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

Hi,

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

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

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

Date: Mon, 18 Feb 2002 18:31:33 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: pkix <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Sender: [email-masked]

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

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

Date: Mon, 18 Feb 2002 17:49:15 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], pkix <[email-masked]>, Tim Polk <[email-masked]>, Stephen Kent <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Sender: [email-masked]

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

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

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

RFC 2026 also states:

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

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

:-)

You will find attached a document in two parts:

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

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

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

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

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

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

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAXgAAAAAAAAAA
EAAAYAAAAAEAAAD+////AAAAAF0AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAA

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

Date: Mon, 18 Feb 2002 11:07:40 -0500
To: pkix <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: agenda topics, WG last call for DPV requirements
Sender: [email-masked]

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

Folks,

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

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

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

Thanks,

Steve
--============_-1198074017==_ma============
Content-Type: text/html; charset="us-ascii"

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

Date: Mon, 18 Feb 2002 15:46:04 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: pkix <[email-masked]>
Subject: Policy requirements for Time-Stamping Authorities
Sender: [email-masked]

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

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

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

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

Denis

From: Peter Sylvester <[email-masked]>
Date: Mon, 18 Feb 2002 12:02:43 +0100 (MET)
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Sender: [email-masked]

Hi, 

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

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

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

Date: Mon, 18 Feb 2002 10:06:25 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Sender: [email-masked]

Anders,

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

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

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

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

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

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

Denis
 
> Anders

From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comment on RFC 2459
Date: Fri, 15 Feb 2002 20:09:53 -0300
Importance: High
Sender: [email-masked]

Russ,

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

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

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

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

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

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

Best regards,

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

Notes:

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

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 15 Feb 2002 10:23:27 -0500
Subject: Re: Comment on RFC 2459
Sender: [email-masked]

Dieter:

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

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

Russ

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

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

From: "Anders Rundgren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Roberto Opazo" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Fri, 15 Feb 2002 16:15:13 +0100
Sender: [email-masked]

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

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

Agreed.

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

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

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

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

Agreed.

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

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

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

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

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

>Applicable to any entity, as the text says.

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

Anders

Date: Fri, 15 Feb 2002 09:54:48 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: draft-ietf-ipsra-pic-05.txt
Sender: [email-masked]

Dear PKIX WG:

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

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

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

Russ

Date: Fri, 15 Feb 2002 12:18:21 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Anders Rundgren <[email-masked]>
CC: Roberto Opazo <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Sender: [email-masked]

Anders,

> Roberto,

> I support issuer PIs as well.

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

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

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

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

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

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

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

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

Applicable to any entity, as the text says.

Denis

> Anders
> From: "Roberto Opazo" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, February 14, 2002 22:01
> Subject: RE: I-D ACTION:draft-ietf-pkix-pi-03.txt
> 
> Congratulations, I think it is very good and necessary.
> 
> I agree with the syntax proposed, but I think the text is not completely
> coherent with the syntax.
> 
> I do not understand why the text has a scope so restricted. The term
>  "Person" in the e-mail abstract is obviously a typing error since it is
> right in the draft using the term "entity". But there is another scope
> restriction, ".may be included in the subjectAltName extension.". Why only
> subjectAltName? The new syntax applies to OtherName type, so in fact it
> applies to every extension witch use a General Name (GN) type, like
> issuerAltName for example. The text is saying "may be", so it is not
> restricting the possibility of using it in another extension, but I think
> there is a space for interpretation, that implies confusion.
> 
> Based on previous conversation with Denis Pinkas, I think this is not a
> typing error, so I would like to post my point.
> 
> Usually we do not have collision problems with CA names, so PIs are less
> necessary for issuers than for subjects, but there are other reasons to use
> a PI, at least consistency and comfort.
> 
> I think consistency is very important, if PI are going to be used, then
> there will be many routines to extract that identifier from one certificate
> and there will be DBs witch use this identifier as record key. So, it will
> be very comfortable and consistent to use the same method to treat entities
> and CAs in DB. Actually, there are many Systems that are not PKI based and
> this systems are using some identifier that will be good candidates to be
> PI. Many of these systems are going to be migrated to use PKI. The
> developers involved has no idea about what DNs are. I think PI will
> facilitate the construction of tools for that people and they will want to
> have a routine to manipulate identifiers, not necessary DN.
> 
> One example: Last year, when we wore discussing the Service of Internal
> Taxes (SII) regulation in Chile to use public key certificates, they said
> they want the certificates to have the Run (Rol único nacional) of the
> subject and the Rut (Rol único tributario) of the issuer. My opinion was not
> in favor of putting de Rut of the CA in certificates because that
> information can be obtained very easily from CPS, CA Web site and Service of
> Internal Taxes resolutions, between others. Other reason to not want to put
> the Rut there was to increase the certificate size, that is not very good
> when you are putting it in a smart card. But people prefer to administrate
> the Run and the Rut in the same way.
> 
> Lets think in an access control database, there you have entities authorized
> identifies by PI, and there you have a list of CAs in which the System
> trust, do you want to identify this CAs by DN or you prefer to use the same
> method used for entities?
> 
> In many cases this CAs are going to be regulated, so there is no risk of not
> finding the CA PI in the certificate if the organization using the DB want
> to use a CA PI.
> 
> Does it sound reasonable to you?
> 
> If not, the syntax proposed in the draft allows it, but the text do not.
> 
> Best regards,
> 
> Roberto Opazo - [email-masked]
> CEO - www.acepta.com
> Certification Authority for Chile
> 
> > -----Mensaje original-----
> > De: [email-masked] [mailto:[email-masked]]En
> > nombre de [email-masked]
> > Enviado el: Jueves 14 de Febrero de 2002 08:05 AM
> > Para: IETF-Announce:
> > CC: [email-masked]
> > Asunto: I-D ACTION:draft-ietf-pkix-pi-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Public-Key Infrastructure
> > (X.509) Working Group of the IETF.
> >
> > Title : Internet X.509 Public Key Infrastructure
> > Permanent
> >                           Identifier
> > Author(s) : D. Pinkas, T. Gindin
> > Filename : draft-ietf-pkix-pi-03.txt
> > Pages : 9
> > Date : 13-Feb-02
> >
> > This document define a new form of name, called permanent
> > identifier, that may be included in the subjectAltName extension
> > of a public key certificate issued to a physical person.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of
> > the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with
> > the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-ietf-pkix-pi-03.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > [email-masked].
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-pkix-pi-03.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >

Date: Fri, 15 Feb 2002 12:02:06 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Sender: [email-masked]

Anders,

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

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

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

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

Denis

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

Subject: Comment on RFC 2459
To: [email-masked]
From: [email-masked]
Date: Fri, 15 Feb 2002 08:54:18 +0100
Sender: [email-masked]

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

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

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

The correct encoding should be:

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

Regards
Dieter Schomaker
_________________________________________________________________
GAD eG, Weseler Str. 500, 48163 Münster   [email-masked]
Tel.: 0251/ 7133-1648                     FAX: 0251/ 7133-1616
_________________________________________________________________

From: "Anders Rundgren" <[email-masked]>
To: "Roberto Opazo" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Thu, 14 Feb 2002 23:06:54 +0100
Sender: [email-masked]

Roberto,
I support issuer PIs as well.

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

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

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

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

Anders

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

Congratulations, I think it is very good and necessary.

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

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

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

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

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

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

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

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

Does it sound reasonable to you?

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

Best regards,

Roberto Opazo - [email-masked]
CEO - www.acepta.com
Certification Authority for Chile

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de [email-masked]
> Enviado el: Jueves 14 de Febrero de 2002 08:05 AM
> Para: IETF-Announce:
> CC: [email-masked]
> Asunto: I-D ACTION:draft-ietf-pkix-pi-03.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure
> (X.509) Working Group of the IETF.
>
> Title : Internet X.509 Public Key Infrastructure
> Permanent
>                           Identifier
> Author(s) : D. Pinkas, T. Gindin
> Filename : draft-ietf-pkix-pi-03.txt
> Pages : 9
> Date : 13-Feb-02
>
> This document define a new form of name, called permanent
> identifier, that may be included in the subjectAltName extension
> of a public key certificate issued to a physical person.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-pkix-pi-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-pkix-pi-03.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

From: "Roberto Opazo" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Thu, 14 Feb 2002 17:01:50 -0400
Importance: Normal
Sender: [email-masked]

Congratulations, I think it is very good and necessary.

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

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

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

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

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

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

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

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

Does it sound reasonable to you?

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

Best regards,

Roberto Opazo – [email-masked]
CEO – www.acepta.com
Certification Authority for Chile

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de [email-masked]
> Enviado el: Jueves 14 de Febrero de 2002 08:05 AM
> Para: IETF-Announce:
> CC: [email-masked]
> Asunto: I-D ACTION:draft-ietf-pkix-pi-03.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure
> (X.509) Working Group of the IETF.
>
> 	Title		: Internet X.509 Public Key Infrastructure
> Permanent
>                           Identifier
> 	Author(s)	: D. Pinkas, T. Gindin
> 	Filename	: draft-ietf-pkix-pi-03.txt
> 	Pages		: 9
> 	Date		: 13-Feb-02
>
> This document define a new form of name, called permanent
> identifier, that may be included in the subjectAltName extension
> of a public key certificate issued to a physical person.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-pkix-pi-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-pi-03.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Thu, 14 Feb 2002 15:09:32 +0100
Sender: [email-masked]

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

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

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

Anders

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Thu, 14 Feb 2002 07:05:18 -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 Permanent 
                          Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-03.txt
	Pages		: 9
	Date		: 13-Feb-02
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to a physical person.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pi-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 14 Feb 2002 11:12:14 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Yee, Peter" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
Sender: [email-masked]

Peter,

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

Yep.

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

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

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

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

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

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: "todd glassey" <[email-masked]>
To: "Cotton Franck" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Cc: "'Tom Gindin'" <[email-masked]>, <[email-masked]>
Subject: Re: Permanent identifier draft
Date: Wed, 13 Feb 2002 11:53:19 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

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

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

  Denis,=20

SNIP

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

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

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

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

  >Looking forward for more information.=20

  >Regards,=20

  >Denis=20

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

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

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

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

From: "Yee, Peter" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
Date: Wed, 13 Feb 2002 11:39:13 -0800
Sender: [email-masked]

Stephen,

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

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

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

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

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

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

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

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

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

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

>Stephen.

							-Peter
							[email-masked]

From: Cotton Franck <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Tom Gindin'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE : Permanent identifier draft
Date: Wed, 13 Feb 2002 18:48:39 +0100
Sender: [email-masked]

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

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

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

Denis,

>Franck,

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

>I agree.

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

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

>to do it this way ?

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

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

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

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

>Looking forward for more information.

>Regards,

>Denis

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

------_=_NextPart_001_01C1B4B6.AB9EC080
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Date: Wed, 13 Feb 2002 16:29:41 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

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

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

Ciao, Michael.

Date: Wed, 13 Feb 2002 16:19:58 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: "Deacon, Alex" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

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

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

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

Ciao, Michael.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc2560bis-01.txt
Date: Wed, 13 Feb 2002 07:10: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		: X.509 Internet Public Key Infrastructure Online 
                          Certificate Status Protocol - OCSP
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-rfc2560bis-01.txt
	Pages		: 
	Date		: 12-Feb-02
	
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc2560bis-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 13 Feb 2002 12:11:40 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Cotton Franck <[email-masked]>
CC: "'Tom Gindin'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Permanent identifier draft
Sender: [email-masked]

Franck,

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

I agree.

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

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

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

Looking forward for more information.

Regards,

Denis

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

From: "todd glassey" <[email-masked]>
To: "LISTS - IETF-PKIX" <[email-masked]>, "LISTS - IETF-IESG" <[email-masked]>, <[email-masked]>
Subject: What is the PKIX TSP anyway?
Date: Tue, 12 Feb 2002 22:09:43 -0800
Sender: [email-masked]

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

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

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

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

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

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

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

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

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

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

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

Todd

Date: Tue, 12 Feb 2002 23:13:27 +0100
From: Petra Barzin <[email-masked]>
To: "Khaja E. Ahmed" <[email-masked]>
Cc: Michael McIntosh <[email-masked]>, Simon Tardell <[email-masked]>, [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

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

CertHash (Positive Statement)

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

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

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

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

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

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

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

From: "Khaja E. Ahmed" <[email-masked]>
To: "Al Arsenault" <[email-masked]>, "Simon Tardell" <[email-masked]>, <[email-masked]>
Subject: Compromised OCSP server Key: Was: RE: Candidate for moving OCSP to a Draft Standard
Date: Tue, 12 Feb 2002 11:04:28 -0800
Importance: Normal
Sender: [email-masked]

Al,

Different problem, different thread.  Answers inline...

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

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

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

Answered in previous response to Michael.

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

From: "Khaja E. Ahmed" <[email-masked]>
To: "Michael McIntosh" <[email-masked]>, "Simon Tardell" <[email-masked]>, <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Tue, 12 Feb 2002 10:50:45 -0800
Importance: Normal
Sender: [email-masked]

Mike,

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

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

Khaja

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

Date: Wed, 13 Feb 2002 06:49:23 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Al Arsenault <[email-masked]> writes:

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

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

Peter.

Date: Tue, 12 Feb 2002 11:57:48 -0500
From: Al Arsenault <[email-masked]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
To: "Khaja E. Ahmed" <[email-masked]>, Simon Tardell <[email-masked]>, [email-masked]
Sender: [email-masked]

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

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

        Al Arsenault
         Chief Security Architect
        Diversinet Corp.

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

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

From: "Deacon, Alex" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Deacon, Alex" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Date: Tue, 12 Feb 2002 07:59:01 -0800
Sender: [email-masked]

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

Alex

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

Date: Tue, 12 Feb 2002 10:21:58 -0500
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

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

Peter,

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

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

Phil :-)

Date: Wed, 13 Feb 2002 02:38:18 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

"Khaja E. Ahmed" <[email-masked]> writes:

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

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

Peter.

Date: Wed, 13 Feb 2002 02:20:08 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Cc: [email-masked]
Sender: [email-masked]

"Deacon, Alex" <[email-masked]> writes:

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

There are two problems with this:

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

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

Peter.

Content-return: allowed
Date: Tue, 12 Feb 2002 04:53:22 -0800
From: Michael McIntosh <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "'Khaja E. Ahmed'" <[email-masked]>, Simon Tardell <[email-masked]>, [email-masked]
Sender: [email-masked]

Khaja,

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

Thanks,
Mike

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

Simon,

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

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

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

Khaja

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

From: Peter Sylvester <[email-masked]>
Date: Tue, 12 Feb 2002 13:08:50 +0100 (MET)
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Cc: [email-masked]
Sender: [email-masked]

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

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

content-class: urn:content-classes:message
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Tue, 12 Feb 2002 10:52:21 +0100
From: "Simon Tardell" <[email-masked]>
To: "Khaja E. Ahmed" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Khaja,

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

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

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

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

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

Simon

Simon Tardell, Software Architect, SmartTrust
voice +46 8 6853174, fax +46 8 6856530
cell +46 70 3198319, [email-masked]

Date: Tue, 12 Feb 2002 10:03:53 +0200
To: [email-masked]
Subject: ;login: special issue
From: Tolga KILICLI <[email-masked]>
Sender: [email-masked]

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

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

Thanks and I am waiting for your comments
Tolga KILICLI

From: "Khaja E. Ahmed" <[email-masked]>
To: "Simon Tardell" <[email-masked]>, <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Mon, 11 Feb 2002 22:59:54 -0800
Importance: Normal
Sender: [email-masked]

Simon,

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

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

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

Khaja

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

From: "Deacon, Alex" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Date: Mon, 11 Feb 2002 14:56:15 -0800
Sender: [email-masked]

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

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

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

Alex

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

From: "todd glassey" <[email-masked]>
To: "Cotton Franck" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "'Tom Gindin'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Permanent identifier draft
Date: Mon, 11 Feb 2002 08:27:38 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

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

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

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

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

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

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

  Denis, Tom=20

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

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

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

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

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

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

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

content-class: urn:content-classes:message
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Mon, 11 Feb 2002 17:13:23 +0100
From: "Simon Tardell" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Khaja,

This case is already catered for in RFC2560:

"2.7  CA Key Compromise

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

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 6853174, fax +46 8 6856530
cell +46 70 3198319, [email-masked]

Date: Mon, 11 Feb 2002 13:51:39 +0000
From: Andreas Sterbenz <[email-masked]>
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

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

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

Andreas.

Date: Tue, 12 Feb 2002 02:04:24 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

"David P. Kemp" <[email-masked]> writes:

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

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

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

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

Peter.

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-02.txt
Date: Mon, 11 Feb 2002 06:56:55 -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		: Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements (DPV&DPD-REQ)
	Author(s)	: D. Pinkas, R. Housley
	Filename	: draft-ietf-pkix-dpv-dpd-req-02.txt
	Pages		: 14
	Date		: 08-Feb-02
	
This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). It also specifies the  requirements for DPV and DPD policy management.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dpv-dpd-req-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
Date: Mon, 11 Feb 2002 06:56: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 
                          Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley
	Filename	: draft-ietf-pkix-logotypes-01.txt
	Pages		: 14
	Date		: 08-Feb-02
	
This document contains an initial outline of a standard for attaching
logotypes to certificates. The draft includes background discussions
around different aspects of problems and solutions, forming a
starting point for the creation of a complete standard.
Please send comments on this document to the [email-masked]
mailing list.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-01.txt

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

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

--OtherAccess--

--NextPart--

From: Cotton Franck <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Tom Gindin'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Permanent identifier draft
Date: Mon, 11 Feb 2002 08:17:27 +0100
Sender: [email-masked]

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

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

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

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

------_=_NextPart_001_01C1B2CC.294DED90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Permanent identifier draft</TITLE>
</HEAD>
<BODY>
<BR>

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

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

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

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

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

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

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

Date: Mon, 11 Feb 2002 20:15:58 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Cc: [email-masked]
Sender: [email-masked]

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

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

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

Peter.

Date: Mon, 11 Feb 2002 19:56:01 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Ambarish Malpani <[email-masked]> writes:

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

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

Peter.

Date: Fri, 08 Feb 2002 19:45:05 -0500
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

Completely understand. Opinion unchanged.

Phil

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

From: "Khaja E. Ahmed" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 8 Feb 2002 15:30:42 -0800
Importance: Normal
Sender: [email-masked]

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

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

Khaja

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

Date: Fri, 8 Feb 2002 17:10:33 -0500
To: "Bill Price" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate's Pointer to its Issuer's Certificate - AIA or IAN
Cc: <[email-masked]>
Sender: [email-masked]

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

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

Bill,

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

Steve
--============_-1198913471==_ma============
Content-Type: text/html; charset="us-ascii"

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

Content-return: allowed
Date: Fri, 08 Feb 2002 14:21:16 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Sender: [email-masked]

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

Regards,
Ambarish

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

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

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

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

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

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

My take on this issue: I believe OCSP is just a revocation status
protocol,
so we should restrict the return status to just revoked, onHold,
notRevoked
and dontKnowAboutThisCA. This would leave the syntax of the protocol
simple and the semantics very clear - OCSP basically returns the same
information that you would get if you had a CRL from the CA at the
instant of the response (NOTE: I am NOT implying that a CRL is ever
issued).

However, if the consensus of the group is that it is important that all
three types of states be returned, I would prefer there to be 3
separate state fields, one for each of the different statii. This would
allow us to add more states in the future (e.g. whether this certificate
can be used for a specific kind of operation, or maybe some information
about the CA of this cert) without affecting these basic status fields.

What do the rest of you on the list feel about this issue:
    - Should OCSP support one or more of these statuses?
    - If we support multiple of these states, should we define separate
        fields, or should we merge all states into one field?

Ambarish

-----------------------End Included Mail-----------

The concensus at that time was that the only status needed was whether
the certificate was revoked or not.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 07, 2002 11:23 PM
> To: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
> 
> 
> "Khaja E. Ahmed" <[email-masked]> writes:
> 
> >This sounds like a perfectly reasonable solution. Surprised 
> it was rejected.
> >After-all this would be an optional extension, why not add it?  
> 
> The reasoning as I recall was that OCSP shouldn't include 
> facilities which
> aren't bug-compatible with CRLs.  Since CRLs can only provide 
> a negative
> response, and even that only for some cases of invalid certs, 
> OCSP doesn't
> include a straighforward yes/no indication.
> 
> (IMHO any poor guy who's stuck with feeding their online 
> status service from
>  offline CRLs has bigger things to worry about than this...).
> 
> Peter.
> 

From: "Housley, Russ" <[email-masked]>
To: Phil Griffin <[email-masked]>
Cc: [email-masked]
Date: Fri, 08 Feb 2002 16:50:22 -0500
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

Hi Phil.

>It seems to me that if you are capable of
>handling a certificate, then handling a sequence
>of certificates is not too much to ask.

On the client side of the HTTP Cert Store, I agree.  However, it is not 
clear that the server side of the HTTP Cert Store needs to do anything with 
the certificate at all.  It is just a blob that needs to be returned to the 
client.

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

Russ

Date: Fri, 08 Feb 2002 16:37:21 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Peter Gutmann wrote:

> They don't provide a positive response, only a negative one.  If a cert is ever
> rendered invalid for *any* reason other than CA revocation, a CRL can't
> indicate this.  Examples of this include the fact that it hasn't become valid
> yet or has expired and the client doesn't realise because its time is out
> (standard practice in the Windows world, the worst I've seen was a system with
> its clock out by several decades), it wasn't regarded as being issued by the CA
> and therefore can't be revoked (which can occur in CMP, see the postings about
> a neverValid CRL status from a while back), or a number of other situations.

A bank or someone with money at stake on certificate validation can be
assumed to have a clock in sync with the rest of the world - Darwin
ensures
that.  So you don't need OCSP or CRLs at all to tell that a certificate
is outside it's validity period, if the answer matters.

If a remote issuance process requires an acceptance receipt before
considering the certificate valid, then the certificate can certainly be
revoked by the CA if the subscriber doesn't acknowledge receipt.
How can you say "can't be revoked" in the same sentence with the
neverValid revocation reason?

> What could be more sensible than having your OCSP responder process
> queries by consulting the central server directly?  If I'm using
> certs for financial transaction authorisation then it may be elegant
> to introduce a 15-minute delay in order to give the crooks a sporting
> chance, but it's not financially satisfying in the long run :-).

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

> Why do CRLs even need to feature in the process, except to highlight their
> deficiencies?  Someone (probably the aforementioned Lynn Wheeler) once said
> that the only reason you'd use an offline mechanism to feed online queries is
> to point out how broken it is.

The fallacy with that reasoning is that CRLs aren't inherently "offline"
any more than a web page is "offline".  Information can be delivered to
a recipient, and cached by that recipient.  If the recipient chooses to
cache web pages or CRLs or OCSP responses, then the recipient is
choosing to be offline. If the recipient never caches, then the
recipient is online.

Source information such as a web cam image, a stock market quote, or a
revocation status is also neither "offline" nor "online", it is only
updated with a certain frequency.  You don't like CAs who update
their CRLs every 24 hours, then suggest that they update them every
15 seconds (to a select group of redistributors, not every end user)
instead.  If I were a CA bidding on a Service Level Agreement to provide
15-second revocation freshness and 1 second response time for 1 million
users, I would bid less to do it using delta CRLs than using Oracle
or Sabre or whatever acceptance system Lynn has in mind.

From: "Bill Price" <[email-masked]>
To: <[email-masked]>
Subject: Certificate's Pointer to its Issuer's Certificate - AIA or IAN
Date: Fri, 8 Feb 2002 16:21:37 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_006C_01C1B0BC.AEB80400
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

PKIX defined the AIA extension which includes a caIssuers type to point to
Issuing CA information. The content of the extension is a general name. The
Issuer Alternative Name (IAN) standard extension which also uses general
names could point to issuer information. Prior to the creation of the AIA
extension, at least one PKI used the URI form of IAN to point to an LDAP
directory entry that contained the issuer's information. The rationale was
to allow retrieval of the issuer's certificate.

I was wondering what was the rationale for not using the IAN when the AIA
caIssuers extension was created. I was also wondering if the PKIX path
discovery work would focus on use of the AIA caIssuers type and disregard
use of the IAN. At least one of the major vendors appears to have ignored
use of the IAN for path creation.

RFC 2459 does not seem to give any guidance on whether or how the IAN and
AIA relate other than what one might conclude from the extension names-IAN
provides an alternate name and AIA provides for information access. It seems
that they would or could have the same content since they both depend on
general names.

Thanks.

Bill Price

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D667483720-08022002>PKIX defined the AIA extension =
which=20
includes a <SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>caIssuers type to point to Issuing CA =
information.=20
The content of the extension is a general name. The Issuer Alternative =
Name=20
(IAN) standard extension which also uses general names could point to =
issuer=20
information. Prior to the creation of the AIA extension, at least one =
PKI used=20
the URI form of IAN to point to an LDAP directory entry that contained =
the=20
issuer's information. The rationale was to allow&nbsp;retrieval of the =
issuer's=20
certificate. </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN></SPAN><SPAN=20
class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>I was wondering what =
was&nbsp;the&nbsp;rationale=20
for not using the IAN when the AIA caIssuers extension was created. I =
was also=20
wondering if the PKIX path discovery work would focus on use of the AIA=20
caIssuers type and disregard use of the IAN. At least one of the major =
vendors=20
appears to have ignored use of the IAN for path=20
creation.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial>RFC 2459 does not seem to give any guidance on whether or =
how the IAN=20
and AIA relate other than what one might conclude from the extension =
names-IAN=20
provides an alternate name and AIA provides for information access. It =
seems=20
that they would or could have the same content since they both depend on =
general=20
names.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial>Thanks.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial>Bill Price</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></SPAN>&nbsp;</DIV>
<P><FONT face=3DArial size=3D2></FONT> </P>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_006C_01C1B0BC.AEB80400--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: X509.v3 Namespace Extension
Date: Fri, 8 Feb 2002 21:52:23 +0100
Sender: [email-masked]

List,
A problem in the X509 world is to create a reasonably robust naming scheme
that allows RP software to *safely* distinguish certificates from different CAs,
using subject attributes based on DN, SubjectAltName, private extensions etc.
Essentially the DN has become useless for separating subjects certified by
different CAs as there is no convention for naming subjects that has any major
acceptance.

There is also a problem with separating different subject types using the same
CA cert+key.

Therefore I propose two non-critical extensions to cope with this.

Both are based on using a URI [RFC2396] as a name-space indicator.
As this has been found to be enough to globally separate the truly giant
amount of different XML Schemas currently in preparation, it should
definitely be satisfactory for X509.v3 certificates.

In addition to separating name-spaces, the extension also allows
CAs to use an http URL (a URI) to point to a document/directory
describing the name-space and the associated subject.

The proposed extensions essentially make an X509.v3 certificate
having three dimensions:
- An issuer/trust dimension
- A subject/entity dimension
- A name-space/entity-type dimension

The last dimension is actually already heavily exploited, based on
conventions (usually hard-coding knowledge about the CA and its
issuance), but would with the proposed extensions, become explicit.

If name-spaces are shared between CAs, the CAs SHOULD follow
the same procedures, and subject formats, so that EE-certificates
can be compared at subject level with no false matches.

One version of the extension is CA-cert-based and vouches
for the *next* level of certificates belonging to a set of defined
name-spaces. 

Another version of the extension would vouch for the certificate
itself, telling what name-space the certificate belongs to.  If the
certificates' CA, has a CA-based name-space extension, one of
the CA-declared name-spaces MUST match that of the certificate.
This extension MUST be specified, if the CA-cert has a CA-level
name-space extension, with more than one declared name-space.

Any thoughts on this?

Anders Rundgren

Content-return: allowed
Date: Fri, 08 Feb 2002 12:08:46 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Hi Peter,
     I was hoping to stay out of this discussion, but I suppose I
need to get back in.

About responders working off CRLs:

In a lot of cases, people have set up our VA (Validation Authority/
OCSP Responder), to run next to a CA, operated by the CA operator.

They have set up the system, so that as soon as there is a new
revocation event, a new CRL is produced, with is immediately
shipped to the VA. The VA now provides revocation information
based on this new CRL.

As I have stated many time before - the problem with CRLs is not
that it takes long to produce them - the problem is with
getting client applications new CRLs as soon as they are
produced. Because of their size, most client applications cache
old CRLs and CAs like this behavior because otherwise their
directory will get overloaded.

With the combination I talked about above, a CA can produce new
CRLs as soon as there is new information, pass that on to the VA
and get the new information to all OCSP clients as they need it.

Hope this helps,
Regards,
Ambarish

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 08, 2002 10:42 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> 
> 
> "David P. Kemp" <[email-masked]> writes:
> 
> >>The reasoning as I recall was that OCSP shouldn't include 
> facilities which
> >>aren't bug-compatible with CRLs.  Since CRLs can only 
> provide a negative
> >>response, and even that only for some cases of invalid 
> certs, OCSP doesn't
> >>include a straighforward yes/no indication.
> >
> >Say what?  CRLs provide positive and negative responses, and 
> the positive
> >response is optimized down to 0 bytes.
> 
> They don't provide a positive response, only a negative one.  
> If a cert is ever
> rendered invalid for *any* reason other than CA revocation, a 
> CRL can't
> indicate this.  Examples of this include the fact that it 
> hasn't become valid
> yet or has expired and the client doesn't realise because its 
> time is out
> (standard practice in the Windows world, the worst I've seen 
> was a system with
> its clock out by several decades), it wasn't regarded as 
> being issued by the CA
> and therefore can't be revoked (which can occur in CMP, see 
> the postings about
> a neverValid CRL status from a while back), or a number of 
> other situations.
> 
> The problem with CRLs is that they ask entirely the wrong 
> question - "Has this
> been revoked?" - when what's really of interest is an answer 
> to the question
> "Is this currently valid?".  This can't really be fixed, 
> because that's the
> only question a blacklist is capable of answering.
> 
> >The reason OCSP can't say that a cert is valid has nothing 
> to do with CRLs.
> >It's crippled by the fact that the request does not include 
> a cert, so the
> >responder can't validate the signature unless it fetches the 
> cert itself.
> >Presumably the OCSP authors made a conscious decision not to 
> require the
> >responder to validate certification paths before providing a 
> response.
> 
> It doesn't need to validate anything.  That's why my text 
> summary went to such
> pains to point out that it was strictly an "account in good 
> standing" query.
> The CA acknowledges that it issued the cert, and that it's 
> currently in good
> standing.  That's all.  There's no validation, path checking, 
> or anything else.
> 
> >>(IMHO any poor guy who's stuck with feeding their online 
> status service from
> >  offline CRLs has bigger things to worry about than this...).
> >
> >Speaking as one such poor guy :-), what's the problem?
> 
> The fact that you're feeding a real-time status process from 
> a source updated
> hourly or daily or whatever (I've seen CAs which issue CRLs 
> in half-day or
> full-day intervals, or which guarantee a CRL age of not more 
> than 24 hours, 8
> hours average-case).
> 
> >What could be more elegant than having your LAN-based OCSP 
> server replicate
> >the PKI revocation database by fetching delta CRLs from the 
> central server
> >every 15 minutes?
> 
> What could be more sensible than having your OCSP responder 
> process queries by
> consulting the central server directly?  If I'm using certs 
> for financial
> transaction authorisation then it may be elegant to introduce 
> a 15-minute delay
> in order to give the crooks a sporting chance, but it's not 
> financially
> satisfying in the long run :-).
> 
> Why do CRLs even need to feature in the process, except to 
> highlight their
> deficiencies?  Someone (probably the aforementioned Lynn 
> Wheeler) once said
> that the only reason you'd use an offline mechanism to feed 
> online queries is
> to point out how broken it is.
> 
> Peter.
> 

Date: Fri, 08 Feb 2002 19:08:15 +0000
From: Dr S N Henson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

Andreas Sterbenz wrote:
> 
> 
> And as pointed out by Dr. Henson, a CMS certlist can be generated
> without an ASN.1 encoder if indefinite length encoding is used.
> 

Needless to say SEQUENCE OF can be handled similarly. Its encoding is:

30 80 <SEQUENCE tag, indefinite length>
	<concatenation of all certificates>
00 00 <EOC>

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

Date: Sat, 9 Feb 2002 07:41:55 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

"David P. Kemp" <[email-masked]> writes:

>>The reasoning as I recall was that OCSP shouldn't include facilities which
>>aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
>>response, and even that only for some cases of invalid certs, OCSP doesn't
>>include a straighforward yes/no indication.
>
>Say what?  CRLs provide positive and negative responses, and the positive
>response is optimized down to 0 bytes.

They don't provide a positive response, only a negative one.  If a cert is ever
rendered invalid for *any* reason other than CA revocation, a CRL can't
indicate this.  Examples of this include the fact that it hasn't become valid
yet or has expired and the client doesn't realise because its time is out
(standard practice in the Windows world, the worst I've seen was a system with
its clock out by several decades), it wasn't regarded as being issued by the CA
and therefore can't be revoked (which can occur in CMP, see the postings about
a neverValid CRL status from a while back), or a number of other situations.

The problem with CRLs is that they ask entirely the wrong question - "Has this
been revoked?" - when what's really of interest is an answer to the question
"Is this currently valid?".  This can't really be fixed, because that's the
only question a blacklist is capable of answering.

>The reason OCSP can't say that a cert is valid has nothing to do with CRLs.
>It's crippled by the fact that the request does not include a cert, so the
>responder can't validate the signature unless it fetches the cert itself.
>Presumably the OCSP authors made a conscious decision not to require the
>responder to validate certification paths before providing a response.

It doesn't need to validate anything.  That's why my text summary went to such
pains to point out that it was strictly an "account in good standing" query.
The CA acknowledges that it issued the cert, and that it's currently in good
standing.  That's all.  There's no validation, path checking, or anything else.

>>(IMHO any poor guy who's stuck with feeding their online status service from
>  offline CRLs has bigger things to worry about than this...).
>
>Speaking as one such poor guy :-), what's the problem?

The fact that you're feeding a real-time status process from a source updated
hourly or daily or whatever (I've seen CAs which issue CRLs in half-day or
full-day intervals, or which guarantee a CRL age of not more than 24 hours, 8
hours average-case).

>What could be more elegant than having your LAN-based OCSP server replicate
>the PKI revocation database by fetching delta CRLs from the central server
>every 15 minutes?

What could be more sensible than having your OCSP responder process queries by
consulting the central server directly?  If I'm using certs for financial
transaction authorisation then it may be elegant to introduce a 15-minute delay
in order to give the crooks a sporting chance, but it's not financially
satisfying in the long run :-).

Why do CRLs even need to feature in the process, except to highlight their
deficiencies?  Someone (probably the aforementioned Lynn Wheeler) once said
that the only reason you'd use an offline mechanism to feed online queries is
to point out how broken it is.

Peter.

Date: Sat, 9 Feb 2002 07:06:33 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Candidate for moving OCSP to a Draft Standard
Cc: [email-masked], [email-masked]
Sender: [email-masked]

"Housley, Russ" <[email-masked]> writes:

>If the extension is specified in an IETF document, then I will gladly issue an
>OID from the PKIX arc.  Otherwise, it is a private extension, and it should
>not be issued an OID from the PKIX arc.

It's not specified anywhere, I'm just nervous about using private OIDs because
(historically) they've proven awkward for implementors to deal with because no-
one knows where they're defined.  This particular one's a bit of a grey area,
it's not specified in an RFC, but since others are going to use it it's not
really private either.  I'm not really fussed about it, it just seemed a bit
cleaner to have a well-known OID.

Peter.

Date: Fri, 08 Feb 2002 12:43:45 -0500
From: "David P. Kemp" <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

Peter Sylvester wrote:
> 
> > Andreas Sterbenz <[email-masked]> writes:
> >
> > Most respondents were in favour of multipart, because they didn't want to build
> > an ASN.1 encoder into their database.
> 
> It seems to me that implementing an encoder for a sequence like
> 
> 30 80 cert1 cert2 ... 00 00
> 
> isn't really a big task,
> and even surrounding this with some fixed magic octets
> representing a p7c message, thus allowing to reuse an
> already existing content-type.
> 
> Or, I seem to share Andreas' disagreement.

If we are taking a straw poll, I agree with Peter, Andreas,
and Phil Griffin.  Multipart is excessive overhead and complexity;
four fixed octets is trivial.

Date: Fri, 08 Feb 2002 12:22:48 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Peter Gutmann wrote:
> 
> "Khaja E. Ahmed" <[email-masked]> writes:
> 
> >This sounds like a perfectly reasonable solution. Surprised it was rejected.
> >After-all this would be an optional extension, why not add it?
> 
> The reasoning as I recall was that OCSP shouldn't include facilities which
> aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
> response, and even that only for some cases of invalid certs, OCSP doesn't
> include a straighforward yes/no indication.

Say what?  CRLs provide positive and negative responses, and the
positive
response is optimized down to 0 bytes.  If you want to know whether a
certificate was issued, the signature on the cert tells you that, and if
it doesn't you've got bigger problems than just revocation status.

The reason OCSP can't say that a cert is valid has nothing to do with
CRLs.
It's crippled by the fact that the request does not include a cert, so
the
responder can't validate the signature unless it fetches the cert
itself.
Presumably the OCSP authors made a conscious decision not to require the
responder to validate certification paths before providing a response.

> (IMHO any poor guy who's stuck with feeding their online status service from
>  offline CRLs has bigger things to worry about than this...).

Speaking as one such poor guy :-), what's the problem?   I have a user
community of 4.5 million people, and having each of them bang against
a central OCSP server every time they do something PKI-related on their
LAN is going to incur their wrath.  Server delays and Internet
congestion shouldn't be designed into local applications, causing
things that should have happened instantaneously to take 5 seconds,
or more when their pipe to the Internet is loaded.

I've learned to ignore Lynn Wheeler when he refers to CRLs as 
'60's-era blacklists (and I can remember when supermarket clerks thumbed
through those little books).  But I expect you'd have a little more
appreciation for simplicity.  What could be more elegant than having
your
LAN-based OCSP server replicate the PKI revocation database by fetching
delta CRLs from the central server every 15 minutes?

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 08 Feb 2002 12:09:07 -0500
Subject: RE: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Peter:

If the extension is specified in an IETF document, then I will gladly issue 
an OID from the PKIX arc.  Otherwise, it is a private extension, and it 
should not be issued an OID from the PKIX arc.

Russ

  At 08:17 PM 2/8/2002 +1300, Peter Gutmann wrote:

>"Florian Oelmaier" <[email-masked]> writes:
>
> >Advantage of OCSP: extensible.
> >
> >Idea: Use advantages heavily.
> >
> >Conclusion: Interested in Peter Gutmanns extension.
> >
> >:) So Peter, plz post the extension and the derscription. Best to the list -
> >then it is somewhat half-official and a lot of other people in the community
> >can use it, too.
>
>Here it is, slightly more formalised than the original source code comment:
>
>-- Snip --
>
>CertificateOK
>
>The CertOK extension sidesteps the limitations of the CRL-based semantics of
>the standard OCSP response and provides a straightforward indication of 
>whether
>a certificate is OK or not.  "OK" in this sense is the equivalent of the
>banking assertion that an account is in good standing, namely that the
>identified certificate was issued and is currently valid.  Further information
>on why a certificate may not be OK can be found in the standard OCSP response.
>
>   id-certOK OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 }
>
>   CertOK ::= BOOLEAN
>
>   [I'll take a PKIX OID in place of the current private one if it's 
> considered
>    worth issuing it]
>
>Rationale
>
>The CertOK response is purely an indication that the account is in good
>standing.  In other words, it provides the information that the OCSP responder
>is likely to possess, but is prevented by the standard OCSP status values from
>providing to the user.  It does not provide, and is not intended to provide, a
>DVCS/DPV/DPD/etc-style checking mechanism (for example, again using banking
>terms, an indication that the account contains enough to cover a given
>transaction, or that the account owner can be trusted to do business with).
>These extended forms of checking are covered in separate standards.
>
>-- Snip --
>
>Peter.

From: Peter Sylvester <[email-masked]>
Date: Fri, 8 Feb 2002 17:52:19 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Cc: [email-masked]
Sender: [email-masked]

> Andreas Sterbenz <[email-masked]> writes:
> 
> Most respondents were in favour of multipart, because they didn't want to build
> an ASN.1 encoder into their database.

It seems to me that implementing an encoder for a sequence like

30 80 cert1 cert2 ... 00 00

isn't really a big task, 
and even surrounding this with some fixed magic octets
representing a p7c message, thus allowing to reuse an 
already existing content-type.

Or, I seem to share Andreas' disagreement.

Date: Fri, 08 Feb 2002 11:40:11 -0500
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

Andreas Sterbenz wrote:
> 
>  > 2. HTTP Certificate Store Interface
> 
>  > If more than one certificate matches a query, it MUST be returned as a
>  > multipart/mixed response.
> 
>  > 2.4 Rationale
> 
>  > Multiple response are returned as multipart/mixed rather than an ASN.1
>  > SEQUENCE OF Certificate or PKCS #7/CMS certificate chain because this
>  > is more straightforward to implement with standard web-enabled tools.
>  > An additional advantage is that it doesn't restrict this access
>  > mechanism to DER-based data, allowing it to be extended to other
>  > certificate types such as XML, PGP, and SPKI.
> 
> I continue to disagree with the decision to use multipart MIME for the
> reasons previously stated by me and others.
> 
> The XML/PGP argument does not seem to carry much weight either, because
> the spec is only targeted at X.509. It also seems questionable that MIME
> would be a suitable choice for XML/PGP any more than it is for X.509.
> 
> [I speak for myself, not for Sun]
> 
> Andreas.

Agree. It seems to me that if you are capable of
handling a certificate, then handling a sequence
of certificates is not too much to ask. Common
industry practice. Reasonably expected capability.

And a bag of certificates is no more difficult for
an application not ASN.1-aware to hand off than a 
single certificate. It's a blob after all.

As to XML markup, that's just another ASN.1
encoding format too now. From the Study Group
17 Secretariat to the public asn1 list at ITU-T:

   "X.680, X.681, X.682, X.683, X.690, X.691 are being
   revised by Question 12 of ITU-T Study Group 17. As
   part of the ITU-T ASN.1 Project, an FTP server was
   set up with the aim of increasing interaction with
   all parties interested in the development of ASN.1
   related standards.

   I am pleased to inform you that the draft revision
   of the set of above mentioned Recommendations has
   been made available on an FTP server for a limited
   period of time (pdf format), and you are invited to
   review these texts to provide any comments that 
   could help to improve the most valuable base texts
   for your future reference.

   In addition, the draft of a new ASN.1-series 
   Recommendation, X.692, on Encoding Control Notation
   (ECN) is also made available on the FTP server. 
 
   Please note that the next scheduled meeting to discuss
   this issue is 27 February - 8 March 2002 (Geneva). If
   you wish to comment, could you please do so prior to
   15 February 2002 by using this e-mail mailing list 
   ([email-masked]) or by direct contact with the Rapporteur
   concerned ([email-masked]). 

   Many thanks in advance for your interest,

   NOTE: 
   asn1 FTP HOST NAME: ties.itu.int, 
   ID asn1, 
   PWD notation1"

Phil Griffin

Date: Fri, 08 Feb 2002 15:55:35 +0000
From: Andreas Sterbenz <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

Peter Gutmann wrote:
> 
>>I continue to disagree with the decision to use multipart MIME for the reasons
>>previously stated by me and others.
> 
> Most respondents were in favour of multipart, because they didn't want to build
> an ASN.1 encoder into their database.

I may be wrong, but here's my count:

multipart: 3 (Peter Gutmann, Russ Housley, Michael Stroeder)
PKCS#7 or SEQUENCE: 3 (Andreas Sterbenz, Peter Sylvester, Eric Murray)

And as pointed out by Dr. Henson, a CMS certlist can be generated 
without an ASN.1 encoder if indefinite length encoding is used.

I don't want to discuss this more than necessary, but I believe another 
look is warranted.

Andreas.

From: Peter Sylvester <[email-masked]>
Date: Fri, 8 Feb 2002 16:31:32 +0100 (MET)
To: [email-masked]
Subject: Re: RFC 3161 (TSP): update for the criticality flag
Sender: [email-masked]

> It will be replaced by:
You probably mean: 

  "I propose to replace it by:"

Date: Sat, 9 Feb 2002 04:19:30 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Cc: [email-masked]
Sender: [email-masked]

Andreas Sterbenz <[email-masked]> writes:

>I continue to disagree with the decision to use multipart MIME for the reasons
>previously stated by me and others.

Most respondents were in favour of multipart, because they didn't want to build
an ASN.1 encoder into their database.

Peter.

Date: Fri, 08 Feb 2002 14:59:05 +0000
From: Andreas Sterbenz <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Sender: [email-masked]

 > 2. HTTP Certificate Store Interface

 > If more than one certificate matches a query, it MUST be returned as a
 > multipart/mixed response.

 > 2.4 Rationale

 > Multiple response are returned as multipart/mixed rather than an ASN.1
 > SEQUENCE OF Certificate or PKCS #7/CMS certificate chain because this
 > is more straightforward to implement with standard web-enabled tools.
 > An additional advantage is that it doesn't restrict this access
 > mechanism to DER-based data, allowing it to be extended to other
 > certificate types such as XML, PGP, and SPKI.

I continue to disagree with the decision to use multipart MIME for the 
reasons previously stated by me and others.

The XML/PGP argument does not seem to carry much weight either, because 
the spec is only targeted at X.509. It also seems questionable that MIME 
would be a suitable choice for XML/PGP any more than it is for X.509.

[I speak for myself, not for Sun]

Andreas.

Date: Fri, 08 Feb 2002 15:32:38 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3161 (TSP): update for the criticality flag
Sender: [email-masked]

Peter,

> Denis Pinkas <[email-masked]> writes:
> 
> >   A server that does not recognize a non-critical extension SHALL
> >   ignore the extension and SHALL not return an error for this.
> >
> >   A server that recognizes an extension SHALL process the extension
> >   regardless of the value of the criticality flag. A server MUST
> >   reject the request if it encounters a critical extension it does
> >   not recognize and in that case SHALL return a failure
> >   (unacceptedExtension).
> 
> This is still in conflict with RFC 2459.  
>
> Why not just use the RFC 2459 semantics?
  
The explanation has already been given by Peter Sylvester in an e-mail 
sent to the PKIX mailing list on Wednesday, 30 Jan 2002.
 
Please read that e-mail on the subsequent thread.

Denis
 
> Peter.

Date: Sat, 9 Feb 2002 03:14:58 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  RFC 3161 (TSP): update for the criticality flag
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>   A server that does not recognize a non-critical extension SHALL
>   ignore the extension and SHALL not return an error for this.
>
>   A server that recognizes an extension SHALL process the extension
>   regardless of the value of the criticality flag. A server MUST
>   reject the request if it encounters a critical extension it does
>   not recognize and in that case SHALL return a failure
>   (unacceptedExtension).

This is still in conflict with RFC 2459.  Why not just use the RFC 2459
semantics?

Peter.

Date: Fri, 08 Feb 2002 14:27:49 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: pkix <[email-masked]>
Subject: RFC 3161 (TSP): update for the criticality flag
Sender: [email-masked]

I am in the process to capture the changes to be done to RFC 3161. 
In response to the comments raised about the criticality flag 
for the extensions.

The current text reads:  

   If an extension, whether it is marked critical or not critical, is
   used by a requester but is not recognized by a time-stamping server,
   the server SHALL not issue a token and SHALL return a failure
   (unacceptedExtension).

It will be replaced by:

   A server that does not recognize a non-critical extension SHALL 
   ignore the extension and SHALL not return an error for this.

   A server that recognizes an extension SHALL process the extension 
   regardless of the value of the criticality flag. A server MUST 
   reject the request if it encounters a critical extension it does 
   not recognize and in that case SHALL return a failure 
   (unacceptedExtension). 

Denis

Date: Fri, 08 Feb 2002 14:15:24 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Miguel Reis <[email-masked]>
CC: [email-masked]
Subject: Re: TSP via HTTP - MIME objects
Sender: [email-masked]

Miguel,

> Hi all,
> 
> RFC3161 says:
> 
> "Content-Type: application/timestamp-reply
> 
>       <<the ASN.1 DER-encoded Time-Stamp Response message>>"
> ...
> 
> "Upon receiving a valid request, the server MUST respond with either a
> valid response with content type application/timestamp-response or
> with an HTTP error."
> 
> My question is:
> 
> The TSA should respond with "application/timestamp-reply" or with
> "application/timestamp-response"?

"application/timestamp-reply". Good catch. Thank you.

Denis

> thanks,
> miguel

Subject: TSP via HTTP - MIME objects
From: Miguel Reis <[email-masked]>
To: [email-masked]
Date: 08 Feb 2002 11:12:22 +0000
Sender: [email-masked]

Hi all,

RFC3161 says:

"Content-Type: application/timestamp-reply

      <<the ASN.1 DER-encoded Time-Stamp Response message>>"

...

"Upon receiving a valid request, the server MUST respond with either a
valid response with content type application/timestamp-response or
with an HTTP error."

My question is:

The TSA should respond with "application/timestamp-reply" or with
"application/timestamp-response"?

thanks,

miguel

Date: Fri, 8 Feb 2002 20:23:18 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Candidate for moving OCSP to a Draft Standard
Cc: [email-masked]
Sender: [email-masked]

"Khaja E. Ahmed" <[email-masked]> writes:

>This sounds like a perfectly reasonable solution. Surprised it was rejected.
>After-all this would be an optional extension, why not add it?  

The reasoning as I recall was that OCSP shouldn't include facilities which
aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
response, and even that only for some cases of invalid certs, OCSP doesn't
include a straighforward yes/no indication.

(IMHO any poor guy who's stuck with feeding their online status service from
 offline CRLs has bigger things to worry about than this...).

Peter.

Date: Fri, 8 Feb 2002 20:17:45 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Candidate for moving OCSP to a Draft Standard
Cc: [email-masked]
Sender: [email-masked]

"Florian Oelmaier" <[email-masked]> writes:

>Advantage of OCSP: extensible.
>
>Idea: Use advantages heavily.
>
>Conclusion: Interested in Peter Gutmanns extension.
>
>:) So Peter, plz post the extension and the derscription. Best to the list -
>then it is somewhat half-official and a lot of other people in the community
>can use it, too.

Here it is, slightly more formalised than the original source code comment:

-- Snip --

CertificateOK

The CertOK extension sidesteps the limitations of the CRL-based semantics of
the standard OCSP response and provides a straightforward indication of whether
a certificate is OK or not.  "OK" in this sense is the equivalent of the
banking assertion that an account is in good standing, namely that the
identified certificate was issued and is currently valid.  Further information
on why a certificate may not be OK can be found in the standard OCSP response.

  id-certOK OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 }

  CertOK ::= BOOLEAN

  [I'll take a PKIX OID in place of the current private one if it's considered
   worth issuing it]

Rationale

The CertOK response is purely an indication that the account is in good
standing.  In other words, it provides the information that the OCSP responder
is likely to possess, but is prevented by the standard OCSP status values from
providing to the user.  It does not provide, and is not intended to provide, a
DVCS/DPV/DPD/etc-style checking mechanism (for example, again using banking
terms, an indication that the account contains enough to cover a given
transaction, or that the account owner can be trusted to do business with).
These extended forms of checking are covered in separate standards.

-- Snip --

Peter.

Reply-To: <[email-masked]>
From: [email-masked] (Miguel Angel Rodriguez)
To: <[email-masked]>
Subject: Response Signer Identity in OCSP
Date: Thu, 7 Feb 2002 17:54:15 -0600
Importance: Normal
Sender: [email-masked]

Regarding section 3.2  Signed Response Acceptance Requirements in
OCSP-draft-03, in point number 3:

3. The identity of the signer matches the intended recipient of the
   request.

What does the client know about the identity of the responder? It knows    a
URL from the AuthorityInfoAccess in a given certifcate, and once it gets the
response it has the responder's certificate, a responderId, which may be a
name or the hash of its public key. But how can a client check that the
responder's identity matches the one of the intended recipient of the
request. Does it imply that the client has to validate the responder's
certificate? What is the purpose of the ResponderID field in the response?

Thanks,

Miguel A. Rodriguez
SeguriDATA
Mexico

From: "Khaja E. Ahmed" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Wed, 6 Feb 2002 19:21:52 -0800
Importance: Normal
Sender: [email-masked]

This sounds like a perfectly reasonable solution. Surprised it was rejected.
After-all this would be an optional extension, why not add it?  ...if for no
other reason than that it would put an end to the 'good' is not good enough
debate.

Khaja

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Wednesday, February 06, 2002 7:25 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Denis Pinkas <[email-masked]> writes:
>
> >2) The "good" status has always been misleading. The text says:
> >
> >   The "good" state indicates that the certificate has not been revoked.
> >
> >According to this definition, which is correct, an unambiguous
> status would
> >better be called: "not revoked" rather than "good".
>
> Uh-oh, the OCSP-status-debate perpetual motion machine has
> started again :-).
> In case anyone's interested, I've been using a private extension
> which tries to
> fix the OCSP status problems, for about a year or so.  It's very
> simple, just a
> boolean when says that the certificate in question exists and is currently
> valid (ie was issued and hasn't expired, been revoked, or
> whatever).  This was
> rejected for addition to OCSP, but if anyone else is interested in adding
> support for this I'll post the details.
>
> Peter.

From: "Florian Oelmaier" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Wed, 6 Feb 2002 19:46:21 +0100
Importance: Normal
Sender: [email-masked]

Advantage of OCSP: extensible.

Idea: Use advantages heavily.

Conclusion: Interested in Peter Gutmanns extension.

:) So Peter, plz post the extension and the derscription. Best to the list -
then it is somewhat half-official and a lot of other people in the community
can use it, too.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Wednesday, February 06, 2002 4:25 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Denis Pinkas <[email-masked]> writes:
>
> >2) The "good" status has always been misleading. The text says:
> >
> >   The "good" state indicates that the certificate has not been revoked.
> >
> >According to this definition, which is correct, an unambiguous
> status would
> >better be called: "not revoked" rather than "good".
>
> Uh-oh, the OCSP-status-debate perpetual motion machine has
> started again :-).
> In case anyone's interested, I've been using a private extension
> which tries to
> fix the OCSP status problems, for about a year or so.  It's very
> simple, just a
> boolean when says that the certificate in question exists and is currently
> valid (ie was issued and hasn't expired, been revoked, or
> whatever).  This was
> rejected for addition to OCSP, but if anyone else is interested in adding
> support for this I'll post the details.
>
> Peter.

Date: Wed, 06 Feb 2002 16:38:24 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Peter,

> >2) The "good" status has always been misleading. The text says:

> >   The "good" state indicates that the certificate has not been revoked.

> >According to this definition, which is correct, an unambiguous status would
> >better be called: "not revoked" rather than "good".
 
> Uh-oh, the OCSP-status-debate perpetual motion machine has started again :-).
> In case anyone's interested, I've been using a private extension which tries to
> fix the OCSP status problems, for about a year or so.  It's very simple, just a
> boolean when says that the certificate in question exists and is currently
> valid (ie was issued and hasn't expired, been revoked, or whatever).  This was
> rejected for addition to OCSP, but if anyone else is interested in adding
> support for this I'll post the details.

Uh-oh, the OCSP-status-debate about "certificate exists" has started again
:-).
Let us close this debate. :-)

Denis

> Peter.

Date: Thu, 7 Feb 2002 04:25:20 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Cc: [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>2) The "good" status has always been misleading. The text says:
>
>   The "good" state indicates that the certificate has not been revoked.
>
>According to this definition, which is correct, an unambiguous status would
>better be called: "not revoked" rather than "good".

Uh-oh, the OCSP-status-debate perpetual motion machine has started again :-).
In case anyone's interested, I've been using a private extension which tries to
fix the OCSP status problems, for about a year or so.  It's very simple, just a
boolean when says that the certificate in question exists and is currently
valid (ie was issued and hasn't expired, been revoked, or whatever).  This was
rejected for addition to OCSP, but if anyone else is interested in adding
support for this I'll post the details.

Peter.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure Certificate and CRL Profile to Proposed Standard
Date: Tue, 05 Feb 2002 18:31:25 -0500
Sender: [email-masked]

The IESG has approved the Internet-Drafts 'Internet X.509 Public Key
Infrastructure' <draft-ietf-pkix-new-part1-12.txt> and 'Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure'
<draft-ietf-pkix-ipki-pkalgs-05.txt> as Proposed Standards. These
documents are the product of the Internet X.509 Public Key
Infrastructure (PKIX) Working Group. The IESG contact persons are Jeff
Schiller and Marcus Leech.

Technical Summary

  These document defines a profile for X.509 Version 3 certificates and
  X.509 Version 2 Certificate Revocation Lists (CRLs) for use on the
  Internet. It addresses both the cryptographic issues (what has to sign
  what) as well as introduces a rich policy framework for determining
  whether or not a particular certificate should be trusted or not in a
  given context.

  Document formats (Certificates and CRL) are defined as are operation
  and management protocols.

Working Group Summary

  These documents are the product of significant discussion and effort
  on the part of the members of the PKIX Working Group. There is Working
  Group Consensus on them.

Protocol Quality

  These specifications were reviewed for the IESG by Jeffrey
  I. Schiller. In addition these documents received significant review
  in the security community and are believed to be correct.

From: Santosh Chokhani <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
Date: Tue, 5 Feb 2002 14:54:05 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C1AE7E.DE105850
Content-Type: text/plain

David: please see my responses in-line

-----Original Message-----
<snip>

X.509 states the following about the CRL DP extension:

         The distributionPoint component identifies the location from which
the CRL can be obtained.
         If this component is absent, the distribution point name defaults
to the CRL issuer name.

Thus, it is possible for a CRL that contains a distribution point name in
the IDP extension to match a certificate with a CRL DP that does not have a
DP field. This can happen in one of two ways: either (1) the cRLIssuer field
is absent from the CRL DP and the certificate issuer = CRL issuer = DP name
in IDP, or (2) the cRLIssuer field is present and the cRLIssuer in the CRL
DP = CRL issuer = DP name in IDP.

Unlike PKIX, X.509 seems to allow for a DistributionPoint in a CRL DP
extension to be empty (i.e., all three optional elements absent). In this
case, the cRLIssuer defaults to the certificate issuer name and the
distributionPoint defaults to the certificate issuer name as well. A CRL
covering this certificate may have an IDP extension with a DP as long as one
the DPs in the extension is the certificate issuer's name. Given this, it
seems logical that certificate with no CRL DP extension would also be
covered by that CRL. PKIX, in section 6.3.3 explicitly states this:

         For the processing of [a CRL that is not pointed to by a CRL DP],
assume a DP
         with both the reasons and the cRLIssuer fields omitted and a
distribution point
         name of the certificate issuer.

Is this wrong? If so, why?

[The intent of not asserting a DP in CRL DP extension was only if CRL Issuer
field was there so that you do not have to put in the same DN twice.  Thus,
I do not think we should consider case 1.  Granted, standard being vague,
your interpretation is valid.  As far as case 2 is concerned, I agree that
if IDP has a DP, and CRL DP has no DP but cRLIssuer, and the CRL DP
cRLIssuer match the IDP DP; or if the CRL DP cRLIssuer match the CRL Issuer
name and IDP has no DP we have the correct CRL.]

On a related note, there does seem to be a problem with the text in X.509.
At the end of section 8.6.2.1, it states:

         If [the CRL DP] extension is flagged non-critical and a
certificate-using system does
         not recognize the extension field type, then that system should
only use the certificate if:

         - it can acquire and check a complete CRL from the authority (that
the latter CRL is complete
           is indicated by the absence of an issuing distribution point
extension field in the CRL);

It is not necessary, however, to use a complete CRL. If one is checking the
status of an end entity certificate, for example, the CRL could have an IDP
extension with onlyContainsUserCerts asserted. One does not need to be able
to process the CRL DP extension to determine that the certificate is covered
by this CRL. Similarly, the IDP extension in the CRL could have an
onlySomeReasons flag.

[In this case, the standard should reference the Annex for what it means for
a CRL to be complete for its scope (i.e., reason codes of interest and/or
entity type]

Dave

------_=_NextPart_001_01C1AE7E.DE105850
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: New-PKIX-Part1 conflict with X.509 (2000)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David: please see my responses in-line</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>X.509 states the following about the CRL DP =
extension:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
distributionPoint component identifies the location from which the CRL =
can be obtained.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
this component is absent, the distribution point name defaults to the =
CRL issuer name.</FONT>
</P>

<P><FONT SIZE=3D2>Thus, it is possible for a CRL that contains a =
distribution point name in the IDP extension to match a certificate =
with a CRL DP that does not have a DP field. This can happen in one of =
two ways: either (1) the cRLIssuer field is absent from the CRL DP and =
the certificate issuer =3D CRL issuer =3D DP name in IDP, or (2) the =
cRLIssuer field is present and the cRLIssuer in the CRL DP =3D CRL =
issuer =3D DP name in IDP.</FONT></P>

<P><FONT SIZE=3D2>Unlike PKIX, X.509 seems to allow for a =
DistributionPoint in a CRL DP extension to be empty (i.e., all three =
optional elements absent). In this case, the cRLIssuer defaults to the =
certificate issuer name and the distributionPoint defaults to the =
certificate issuer name as well. A CRL covering this certificate may =
have an IDP extension with a DP as long as one the DPs in the extension =
is the certificate issuer's name. Given this, it seems logical that =
certificate with no CRL DP extension would also be covered by that CRL. =
PKIX, in section 6.3.3 explicitly states this:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For =
the processing of [a CRL that is not pointed to by a CRL DP], assume a =
DP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
with both the reasons and the cRLIssuer fields omitted and a =
distribution point</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
name of the certificate issuer.</FONT>
</P>

<P><FONT SIZE=3D2>Is this wrong? If so, why?</FONT>
</P>

<P><FONT SIZE=3D2>[The intent of not asserting a DP in CRL DP extension =
was only if CRL Issuer field was there so that you do not have to put =
in the same DN twice.&nbsp; Thus, I do not think we should consider =
case 1.&nbsp; Granted, standard being vague, your interpretation is =
valid.&nbsp; As far as case 2 is concerned, I agree that if IDP has a =
DP, and CRL DP has no DP but cRLIssuer, and the CRL DP cRLIssuer match =
the IDP DP; or if the CRL DP cRLIssuer match the CRL Issuer name and =
IDP has no DP we have the correct CRL.]</FONT></P>

<P><FONT SIZE=3D2>On a related note, there does seem to be a problem =
with the text in X.509. At the end of section 8.6.2.1, it =
states:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
[the CRL DP] extension is flagged non-critical and a certificate-using =
system does</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not =
recognize the extension field type, then that system should only use =
the certificate if:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - it =
can acquire and check a complete CRL from the authority (that the =
latter CRL is complete</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
is indicated by the absence of an issuing distribution point extension =
field in the CRL);</FONT>
</P>

<P><FONT SIZE=3D2>It is not necessary, however, to use a complete CRL. =
If one is checking the status of an end entity certificate, for =
example, the CRL could have an IDP extension with onlyContainsUserCerts =
asserted. One does not need to be able to process the CRL DP extension =
to determine that the certificate is covered by this CRL. Similarly, =
the IDP extension in the CRL could have an onlySomeReasons =
flag.</FONT></P>

<P><FONT SIZE=3D2>[In this case, the standard should reference the =
Annex for what it means for a CRL to be complete for its scope (i.e., =
reason codes of interest and/or entity type]</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1AE7E.DE105850--

Date: Tue, 05 Feb 2002 12:19:48 -0500
To: "[email-masked]'" <[email-masked]>
From: "David A. Cooper" <[email-masked]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
Sender: [email-masked]

At 10:38 AM 2/5/02 -0500, Santosh Chokhani wrote:

>I agree with Rich on this one. 
>
>I think if the CRL DP does not have DP field, the IDP in the CRL should not have one either. 
>
>That seems that safest thing to do. 
>
>Once a DP field is present a CRL IDP extension, there is no way for a client to determine whether a CRL is complete for its scope.

Santosh,

X.509 states the following about the CRL DP extension:

         The distributionPoint component identifies the location from which the CRL can be obtained.
         If this component is absent, the distribution point name defaults to the CRL issuer name.

Thus, it is possible for a CRL that contains a distribution point name in the IDP extension to match a certificate with a CRL DP that does not have a DP field. This can happen in one of two ways: either (1) the cRLIssuer field is absent from the CRL DP and the certificate issuer = CRL issuer = DP name in IDP, or (2) the cRLIssuer field is present and the cRLIssuer in the CRL DP = CRL issuer = DP name in IDP.

Unlike PKIX, X.509 seems to allow for a DistributionPoint in a CRL DP extension to be empty (i.e., all three optional elements absent). In this case, the cRLIssuer defaults to the certificate issuer name and the distributionPoint defaults to the certificate issuer name as well. A CRL covering this certificate may have an IDP extension with a DP as long as one the DPs in the extension is the certificate issuer's name. Given this, it seems logical that certificate with no CRL DP extension would also be covered by that CRL. PKIX, in section 6.3.3 explicitly states this:

         For the processing of [a CRL that is not pointed to by a CRL DP], assume a DP
         with both the reasons and the cRLIssuer fields omitted and a distribution point
         name of the certificate issuer.

Is this wrong? If so, why?

On a related note, there does seem to be a problem with the text in X.509. At the end of section 8.6.2.1, it states:

         If [the CRL DP] extension is flagged non-critical and a certificate-using system does
         not recognize the extension field type, then that system should only use the certificate if:

         - it can acquire and check a complete CRL from the authority (that the latter CRL is complete
           is indicated by the absence of an issuing distribution point extension field in the CRL);

It is not necessary, however, to use a complete CRL. If one is checking the status of an end entity certificate, for example, the CRL could have an IDP extension with onlyContainsUserCerts asserted. One does not need to be able to process the CRL DP extension to determine that the certificate is covered by this CRL. Similarly, the IDP extension in the CRL could have an onlySomeReasons flag.

Dave

From: Santosh Chokhani <[email-masked]>
To: "Nicholas, Richard" <[email-masked]>, "'David A. Cooper'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
Date: Tue, 5 Feb 2002 10:38:12 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C1AE5B.1EEA8EF0
Content-Type: text/plain

I agree with Rich on this one.

I think if the CRL DP does not have DP field, the IDP in the CRL should not
have one either.

That seems that safest thing to do.

Once a DP field is present a CRL IDP extension, there is no way for a client
to determine whether a CRL is complete for its scope.

-----Original Message-----
From: Nicholas, Richard [mailto:[email-masked]]
Sent: Monday, February 04, 2002 3:54 PM
To: 'David A. Cooper'; [email-masked]'
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)

Dave,

See my comments below.

> The important question is not whether a CRL is complete, but 
> whether it covers the certificate of interest. On this issue, 
> I believe that PKIX and X.509 are in agreement.
> 
> The text in section 6.3.3 does not say anything about whether 
> a CRL is complete. It merely says that a CRL containing a 
> distribution point field in an IDP CRL extension covers a 
> certificate if the DP name matches the certificate issuer's name.
> 
> In X.509, section B.5.1 provides rules for determining 
> whether a certificate is covered by a CRL. If a CRL meets the 
> criteria in section B.5.1.1 (Complete CRL) then it is a 
> complete CRL and thus covers all certificates issued by the 
> CRL issuer.
> 
> If the CRL contains an IDP extension with a distribution 
> point name, then section B.5.1.4 (Distribution point based 
> CRL/EPRL/CARL) applies. This section states that if the 
> distribution point name in the IDP extension is present, it 
> must match one of the names in the distribution point or CRL 
> issuer field in the CRL DP in the certificate.
> 
> Section 8.6.2.1 in X.509 states that if the distribution 
> point name is absent from the CRL DP extension then "the 
> distribution point name defaults to the CRL issuer name". 
> Thus, under the scenario that you mentioned, an algorithm 
> that follows X.509 will accept the CRL as covering the certificate.
> 
> Dave

The text you quoted from section 8.6.2.1 in X.509 is not meant to imply that
all certs have distribution points, only to specify what name to use when
the optional distributionPoint component is absent.

In the cases where either:
1.  the CRL distribution points extension is absent, or
2.  the CRL distribution points have been processed, but not all revocation
reasons have been checked,
the software will then attempt to acquire and validate a complete CRL that
covers the remaining reason codes for the type of cert (CA or EE).

In those cases, the software follows the X.509 rules specified for complete
CRLs, since that is the type of CRL it requires -- not a distribution point
CRL.  The presence of an IDP extension in a CRL does not make the CRL a DP
CRL -- even complete CRLs can contain IDP extensions.

- Rich

------_=_NextPart_001_01C1AE5B.1EEA8EF0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: New-PKIX-Part1 conflict with X.509 (2000)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Rich on this one.</FONT>
</P>

<P><FONT SIZE=3D2>I think if the CRL DP does not have DP field, the IDP =
in the CRL should not have one either.</FONT>
</P>

<P><FONT SIZE=3D2>That seems that safest thing to do.</FONT>
</P>

<P><FONT SIZE=3D2>Once a DP field is present a CRL IDP extension, there =
is no way for a client to determine whether a CRL is complete for its =
scope.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Nicholas, Richard [<A =
HREF=3D"mailto:[email-masked]">mailto:Richard.Nichola=
[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, February 04, 2002 3:54 PM</FONT>
<BR><FONT SIZE=3D2>To: 'David A. Cooper'; [email-masked]'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: New-PKIX-Part1 conflict with X.509 =
(2000)</FONT>
</P>
<BR>
<BR>

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

<P><FONT SIZE=3D2>See my comments below.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The important question is not whether a CRL is =
complete, but </FONT>
<BR><FONT SIZE=3D2>&gt; whether it covers the certificate of interest. =
On this issue, </FONT>
<BR><FONT SIZE=3D2>&gt; I believe that PKIX and X.509 are in =
agreement.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The text in section 6.3.3 does not say anything =
about whether </FONT>
<BR><FONT SIZE=3D2>&gt; a CRL is complete. It merely says that a CRL =
containing a </FONT>
<BR><FONT SIZE=3D2>&gt; distribution point field in an IDP CRL =
extension covers a </FONT>
<BR><FONT SIZE=3D2>&gt; certificate if the DP name matches the =
certificate issuer's name.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In X.509, section B.5.1 provides rules for =
determining </FONT>
<BR><FONT SIZE=3D2>&gt; whether a certificate is covered by a CRL. If a =
CRL meets the </FONT>
<BR><FONT SIZE=3D2>&gt; criteria in section B.5.1.1 (Complete CRL) then =
it is a </FONT>
<BR><FONT SIZE=3D2>&gt; complete CRL and thus covers all certificates =
issued by the </FONT>
<BR><FONT SIZE=3D2>&gt; CRL issuer.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the CRL contains an IDP extension with a =
distribution </FONT>
<BR><FONT SIZE=3D2>&gt; point name, then section B.5.1.4 (Distribution =
point based </FONT>
<BR><FONT SIZE=3D2>&gt; CRL/EPRL/CARL) applies. This section states =
that if the </FONT>
<BR><FONT SIZE=3D2>&gt; distribution point name in the IDP extension is =
present, it </FONT>
<BR><FONT SIZE=3D2>&gt; must match one of the names in the distribution =
point or CRL </FONT>
<BR><FONT SIZE=3D2>&gt; issuer field in the CRL DP in the =
certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Section 8.6.2.1 in X.509 states that if the =
distribution </FONT>
<BR><FONT SIZE=3D2>&gt; point name is absent from the CRL DP extension =
then &quot;the </FONT>
<BR><FONT SIZE=3D2>&gt; distribution point name defaults to the CRL =
issuer name&quot;. </FONT>
<BR><FONT SIZE=3D2>&gt; Thus, under the scenario that you mentioned, an =
algorithm </FONT>
<BR><FONT SIZE=3D2>&gt; that follows X.509 will accept the CRL as =
covering the certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
</P>

<P><FONT SIZE=3D2>The text you quoted from section 8.6.2.1 in X.509 is =
not meant to imply that</FONT>
<BR><FONT SIZE=3D2>all certs have distribution points, only to specify =
what name to use when</FONT>
<BR><FONT SIZE=3D2>the optional distributionPoint component is =
absent.</FONT>
</P>

<P><FONT SIZE=3D2>In the cases where either:</FONT>
<BR><FONT SIZE=3D2>1.&nbsp; the CRL distribution points extension is =
absent, or</FONT>
<BR><FONT SIZE=3D2>2.&nbsp; the CRL distribution points have been =
processed, but not all revocation</FONT>
<BR><FONT SIZE=3D2>reasons have been checked,</FONT>
<BR><FONT SIZE=3D2>the software will then attempt to acquire and =
validate a complete CRL that</FONT>
<BR><FONT SIZE=3D2>covers the remaining reason codes for the type of =
cert (CA or EE).</FONT>
</P>

<P><FONT SIZE=3D2>In those cases, the software follows the X.509 rules =
specified for complete</FONT>
<BR><FONT SIZE=3D2>CRLs, since that is the type of CRL it requires -- =
not a distribution point</FONT>
<BR><FONT SIZE=3D2>CRL.&nbsp; The presence of an IDP extension in a CRL =
does not make the CRL a DP</FONT>
<BR><FONT SIZE=3D2>CRL -- even complete CRLs can contain IDP =
extensions.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1AE5B.1EEA8EF0--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-acmc-00.txt
Date: Tue, 05 Feb 2002 09:52:17 -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		: Attribute Certificate Management Messages over CMS
	Author(s)	: P. Yee
	Filename	: draft-ietf-pkix-acmc-00.txt
	Pages		: 8
	Date		: 04-Feb-02
	
This document specifies modifications to the Certificate Management
Messages over CMS specification ([CMCbis]) to permit the management
of attribute certificates.  This document does not stand alone, but
must be used in conjunction with [CMCbis].  It is expected that the
modifications proposed here will also be used in conjunction with the
Attribute Certificate Request Message Format specification ([ACRMF]).

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc2560bis-00.txt
Date: Tue, 05 Feb 2002 09:52:12 -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		: X.509 Internet Public Key Infrastructure Online 
                          Certificate Status Protocol - OCSP
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-rfc2560bis-00.txt
	Pages		: 
	Date		: 04-Feb-02
	
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 05 Feb 2002 14:56:51 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Ambarish Malpani <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Ambarish,

(...)

> > Three remarks:

> > 1) It would be interresting to say what happens in case an
> > OCSP request is made after the end of the validity period 
> > of a certificate.

> > nextUpdate is currently defined as: "The time at or before which 
> > newer information will be available about the status of *the* 
> > certificate".

> > If the certificate has expired, such information about *that*
> > certificate will never be available. Anyway, since the server 
> > does not necessarily have access to the end-entity certificate, 
> > then it does not even know that the certificate has expired.

> > A more appropriate definition about nextUpdate would be: "The
> > time at or before which newer status revocation information 
> > will be available from the CA which has issued the certificate".
 
> I disagree. A responder can get its information from a CA or some
> other source. Nothing in OCSP restricts or implies restrictions
> on the sources of information for a responder.

You are right, but my point was to stress the fact that the OCSP responder
may not know when newer information about the status of *the* certificate 
will be available. So a correction is needed. What about the following:

"The time at or before which newer status revocation information will be
available". 

or much longer, but still exact:

"The time at or before which newer status revocation information will be
available either from the CA who issued the certificate in question, a
Trusted Responder whose public key is trusted by the requestor, or a CA
Designated Responder (Authorized Responder) who holds a specially marked
certificate issued directly by the CA, indicating that the responder may
issue OCSP responses for that CA."

> > In addition, some guidance, in particular in the security
> > considerations section would be useful. Here is some tentative text:

> > An OCSP response does not indicate that the certificate is in
> > that thisUpdate is within the validity period of the end-entity 
> > certificate, which means that clients MUST be able to parse the 
> > end-entity certificate to interpret the validity period.
 
> This is already present in the text. Are you just asking for it
> to be re-iterated in the Security Considerations section?
> (it is in the section that explains good)

No change in the main body of the document but an addition in the Security
Considerations section to explain the implications.

Denis

(...)

From: "Anders Rundgren" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>
Subject: Re: Globally unique DNs - Why?
Date: Mon, 4 Feb 2002 22:59:47 +0100
Sender: [email-masked]

Thanx Phill,
I was also hoping that this was a technically incorrect statement
[not only that it gramatically got a bit weird :-)]

We do though have a practical problem with RPs that handle certificates
from a multitude of CAs that also may issue a multitude of
certificate-types.  I.e. spanning potentially n*m disjunct (and in a few cases
shared), name-spaces.

Therefore I suggested a small XML-schema-inspired X509 "patch", in my reply
to Steve, to reduce name-space hassles a bit.

cheers,
Anders

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Monday, February 04, 2002 16:44
Subject: RE: Globally unique DNs - Why?

> List,
> In certain, rather "animated" discussions, the statement that an
> X509.v3 Subject DN (if specified) must be globally unique in order
> to be "conformant".

That statement is illogical.

If we have a name A that is in a subject DN and someone else decides
to use the name A then according to the statement made both DNs would
then be non-conformant.

This would mean that someone could perform a non-conformance attack on
any certificate they chose which recalls Deep Thought's ripost to 
Broomfondle "And who would that inconvenience?"

If X.400 mail was likely to suplant SMTP the issue of unique names 
would be relevant and a solution would have been found. As it is
not, no solution is needed.

Phill

From: "Nicholas, Richard" <[email-masked]>
To: "'David A. Cooper'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
Date: Mon, 4 Feb 2002 15:54:18 -0500 
Sender: [email-masked]

Dave,

See my comments below.

> The important question is not whether a CRL is complete, but 
> whether it covers the certificate of interest. On this issue, 
> I believe that PKIX and X.509 are in agreement.
> 
> The text in section 6.3.3 does not say anything about whether 
> a CRL is complete. It merely says that a CRL containing a 
> distribution point field in an IDP CRL extension covers a 
> certificate if the DP name matches the certificate issuer's name.
> 
> In X.509, section B.5.1 provides rules for determining 
> whether a certificate is covered by a CRL. If a CRL meets the 
> criteria in section B.5.1.1 (Complete CRL) then it is a 
> complete CRL and thus covers all certificates issued by the 
> CRL issuer.
> 
> If the CRL contains an IDP extension with a distribution 
> point name, then section B.5.1.4 (Distribution point based 
> CRL/EPRL/CARL) applies. This section states that if the 
> distribution point name in the IDP extension is present, it 
> must match one of the names in the distribution point or CRL 
> issuer field in the CRL DP in the certificate.
> 
> Section 8.6.2.1 in X.509 states that if the distribution 
> point name is absent from the CRL DP extension then "the 
> distribution point name defaults to the CRL issuer name". 
> Thus, under the scenario that you mentioned, an algorithm 
> that follows X.509 will accept the CRL as covering the certificate.
> 
> Dave

The text you quoted from section 8.6.2.1 in X.509 is not meant to imply that
all certs have distribution points, only to specify what name to use when
the optional distributionPoint component is absent.

In the cases where either:
1.  the CRL distribution points extension is absent, or
2.  the CRL distribution points have been processed, but not all revocation
reasons have been checked,
the software will then attempt to acquire and validate a complete CRL that
covers the remaining reason codes for the type of cert (CA or EE).

In those cases, the software follows the X.509 rules specified for complete
CRLs, since that is the type of CRL it requires -- not a distribution point
CRL.  The presence of an IDP extension in a CRL does not make the CRL a DP
CRL -- even complete CRLs can contain IDP extensions.

- Rich

Content-return: allowed
Date: Mon, 04 Feb 2002 12:05:41 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Hi Denis,
    Responses inline.

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: Monday, February 04, 2002 5:05 AM
> To: Ambarish Malpani
> Cc: [email-masked]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> 
> Ambarish,
> 
> Three remarks:
> 
> 1) It would be interresting to say what happens in case an 
> OCSP request
>    is made after the end of the validity period of a certificate.
> 
> nextUpdate is currently defined as: "The time at or before which newer
> information will be available about the status of *the* certificate".
> 
> If the certificate has expired, such information about *that* 
> certificate
> will never be available. Anyway, since the server does not 
> necessarily have
> access to the end-entity certificate, then it does not even 
> know that the
> certificate has expired.
> 
> A more appropriate definition about nextUpdate would be: "The 
> time at or
> before which newer status revocation information will be 
> available from the
> CA which has issued the certificate".

I disagree. A responder can get its information from a CA or some
other source. Nothing in OCSP restricts or implies restrictions
on the sources of information for a responder.

> 
> In addition, some guidance, in particular in the security 
> considerations
> section would be useful. Here is some tentative text:
> 
> An OCSP response does not indicate that the certificate is in 
> its validity
> interval. So, it is up to the clients to make sure that thisUpdate is
> within the validity period of the end-entity certificate, 
> which means that
> clients MUST be able to parse the end-entity certificate to 
> interpret the
> validity period.

This is already present in the text. Are you just asking for it
to be re-iterated in the Security Considerations section?
(it is in the section that explains good)

> 
> 
> 2) The "good" status has always been misleading. The text says: 
> 
>    The "good" state indicates that the certificate has not 
> been revoked.
> 
> According to this definition, which is correct, an 
> unambiguous status would
> better be called: "not revoked" rather than "good".

We went through this discussion a few times around earlier. I believe
"good" has been adequately explained here. I don't see any point in
raising this topic again.

> 
> 
> 3) A typo (suppress one "is"):
> 
>    It does not indicate that the certificate was ever issued,
>    is or is in its validity interval.
> 
> should be changed into:
> 
>    It does not indicate that the certificate was ever issued,
>    or is in its validity interval.

Will fix.

> 
> 
> Denis
> 
>  
> > Hi Guys,
> >     Here is a candidate for moving OCSP to a Draft Standard. There
> > are no changes in the bytes that go across the wire - basically all
> > clarifications.
> > 
> > A list of all the changes between this document and RFC 2560 are
> > in Appendix D (reproduced here).
> > 
> > I hope we can get to the Draft Standard state before this IETF.
> > 
> > Regards,
> > Ambarish
> > 
> > Appendix D. Changes
> > 
> >    This section contains the differences in this document 
> from RFC 2560
> > 
> >    - Mention Appendix D in Section 1 and added an appendix D.
> >    - Added a paragraph in Section 1 equating a client with 
> a requestor and
> >      server with responder
> >    - Section 2.2 - clarified the explanation of good, 
> revoked and unknown
> >    - Added Section 2.8 requiring clients and responders to 
> support HTTP
> >    - Added a note at the end of section 3.2, which allows a 
> client to
> >      accept a response that provides statuses for only some of the
> >      certificates requested.
> >    - Clarified the issuerKeyHash in Section 4.1.1
> >    - Added "DER encoding of the" in the third paragraph 
> Section 4.1.2
> >    - Section 4.2.1 - clarified that the signature is on the 
> DER encoding
> >      of tbsResponseData (and not its hash)
> >    - Section 4.2.1 - specified the use of the certs field in
> >      BasicOCSPResponse
> >    - Section 4.2.1 - clarified how you compute KeyHash when 
> providing
> >      the ResponderID byKey.
> >    - Section 4.2.2.2 - removed an extra quote in point 3
> >    - Section 4.3 - Made RSA mandatory. Also changed the 
> references to
> >      point to the appropriate documents. Added the references to the
> >      References section
> >    - Section 4.4.1 - Clarified that a nonce in the request MUST be
> >    - included in the response for the response to be trusted.
> >    - Appendix A - A.1.1. - Got rid of support for GET - not 
> sure that
> >      anybody does it. It is also unclear how a server would tell a
> >      client to ever use GET in the URL specified in the AIA
> >    - Add the module tag for the ASN.1 in OCSP
> >    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE 
> SIZE(1..MAX) of
> >      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
> >      ambiguity of whether the optional sequence may be present, but
> >      with 0 elements. This was done by definining a new 
> element called
> >      Certificates, which is used. Look at the defintion of both
> >      Signature and BasicOCSPResponse.
> >    - Clarified the meaning of nextUpdate being absent (Section 2.4)
> >    - Fixed typo where we referred to id-ad-ocspSigning, to 
> reflect the
> >      correct OID - id-kp-OCSPSigning
> >    - Clarified criteria for response acceptance (Section 3.2)
> >    - Added a line in Section 5 indicating that nonces can be used to
> >      prevent prevent attacks using replays of precomputed responses
> >    - Added a paragraph in Section 5 requiring nonces to be 
> unique for
> >      replay protection
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
http://www.valicert.com
> Mountain View, CA 94043
----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

Date: Mon, 04 Feb 2002 13:49:14 -0500
To: "Nicholas, Richard" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "David A. Cooper" <[email-masked]>
Subject: Re: New-PKIX-Part1 conflict with X.509 (2000)
Sender: [email-masked]

Rich,

The important question is not whether a CRL is complete, but whether it covers the certificate of interest. On this issue, I believe that PKIX and X.509 are in agreement.

The text in section 6.3.3 does not say anything about whether a CRL is complete. It merely says that a CRL containing a distribution point field in an IDP CRL extension covers a certificate if the DP name matches the certificate issuer's name.

In X.509, section B.5.1 provides rules for determining whether a certificate is covered by a CRL. If a CRL meets the criteria in section B.5.1.1 (Complete CRL) then it is a complete CRL and thus covers all certificates issued by the CRL issuer.

If the CRL contains an IDP extension with a distribution point name, then section B.5.1.4 (Distribution point based CRL/EPRL/CARL) applies. This section states that if the distribution point name in the IDP extension is present, it must match one of the names in the distribution point or CRL issuer field in the CRL DP in the certificate.

Section 8.6.2.1 in X.509 states that if the distribution point name is absent from the CRL DP extension then "the distribution point name defaults to the CRL issuer name". Thus, under the scenario that you mentioned, an algorithm that follows X.509 will accept the CRL as covering the certificate.

Dave

At 12:18 PM 2/4/02 -0500, Nicholas, Richard wrote:

>All,
>
>Even though the new PKIX part 1 Internet Draft references X.509 (06/1997),
>rather than X.509 (03/2000), I wanted to point out the following conflict
>between the new PKIX part 1 text and X.509 (2000).
>
>Annex B to X.509 (2000) provides detailed CRL processing rules for
>validating CRLs prior to their use.  Specifically, for complete CRLs, Annex
>B requires the following to be true:
>
>    Issuing distribution point extension may be present; and
>    Issuing distribution point extension shall not contain
>    distribution point field;
>
>However, the algorithm used in the draft-ietf-pkix-new-part1-12.txt, section
>6.3.3, allows a distribution point field in an IDP CRL extension of a
>complete CRL as long as it matches the either the certificate issuer DN or
>one of the issuer alternative names in the cert.
>
>The result:  Software that processes complete CRLs in accordance with X.509
>(2000) will reject PKIX-compliant complete CRLs that contain distribution
>point fields in the IDP extension.
>
>Recommend the new PKIX part1 Internet Draft be updated to be consistent with
>the algorithm used in X.509 (2000).
>
>- Rich

From: "Nicholas, Richard" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: New-PKIX-Part1 conflict with X.509 (2000)
Date: Mon, 4 Feb 2002 12:18:44 -0500 
Sender: [email-masked]

All,

Even though the new PKIX part 1 Internet Draft references X.509 (06/1997),
rather than X.509 (03/2000), I wanted to point out the following conflict
between the new PKIX part 1 text and X.509 (2000).

Annex B to X.509 (2000) provides detailed CRL processing rules for
validating CRLs prior to their use.  Specifically, for complete CRLs, Annex
B requires the following to be true:

   Issuing distribution point extension may be present; and
   Issuing distribution point extension shall not contain
   distribution point field;

However, the algorithm used in the draft-ietf-pkix-new-part1-12.txt, section
6.3.3, allows a distribution point field in an IDP CRL extension of a
complete CRL as long as it matches the either the certificate issuer DN or
one of the issuer alternative names in the cert.

The result:  Software that processes complete CRLs in accordance with X.509
(2000) will reject PKIX-compliant complete CRLs that contain distribution
point fields in the IDP extension.

Recommend the new PKIX part1 Internet Draft be updated to be consistent with
the algorithm used in X.509 (2000).

- Rich
---------------------------
Richard E. Nicholas
Principal Secure Systems Engineer
Getronics Government Solutions, LLC
[email-masked]
(301) 939-2722

From: "Hallam-Baker, Phillip" <[email-masked]>
To: Anders Rundgren <[email-masked]>, [email-masked]
Subject: RE: Globally unique DNs - Why?
Date: Mon, 4 Feb 2002 07:44:07 -0800 
Sender: [email-masked]

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

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

> List,
> In certain, rather "animated" discussions, the statement that an
> X509.v3 Subject DN (if specified) must be globally unique in order
> to be "conformant".

That statement is illogical.

If we have a name A that is in a subject DN and someone else decides
to use the name A then according to the statement made both DNs would
then be non-conformant.

This would mean that someone could perform a non-conformance attack on
any certificate they chose which recalls Deep Thought's ripost to 
Broomfondle "And who would that inconvenience?"

If X.400 mail was likely to suplant SMTP the issue of unique names 
would be relevant and a solution would have been found. As it is
not, no solution is needed.

	Phill

------_=_NextPart_000_01C1AD92.C7C15050
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:[email-masked]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1AD92.C7C15050--

Date: Mon, 4 Feb 2002 10:24:45 -0500
To: jim <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Globally unique DNs - Why?
Cc: [email-masked]
Sender: [email-masked]

At 11:06 PM -0500 2/2/02, jim wrote:
>Point of clarification.  There is a difference between the 
>Distinguished Name (DN) and the Directory Distinguished Name (DDN). 
>The DN is the X.500 naming structure that goes from the root naming 
>structure of the directory to the outer branches and leaf entry for 
>an individual or role.  In LDAP directories, the structure is still 
>used, but from the individual or role moving up to the root entry. 
>The DDN, on the other hand, is the trail of authorizations for a 
>user moving from the issuing Certification Authority up to the root 
>issuing authority, be it a Policy Approving Authority in a very 
>hierarchical structure or the chief CA in a ring set up.  My 
>experience is that confusion of the two, DN and DDN, almost always 
>leads to lack of understanding of how the system needs to work.
>Jim

Jim,

Could you cite the standard from which your definition of DDN comes? 
I have never heard that characterization before.

Steve

Date: Mon, 04 Feb 2002 10:52:24 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

Peter,

> Denis Pinkas <[email-masked]> writes:
> 
> >>To some extent, although you'd need to allow anyPolicy to allow the client to
> >>specify that if it can't get an exact match, anything will do.
> >
> >If anything will do, then the client does not need to request any specific
> >policy.
> 
> And how does this help if the client wants one of a set of policies, but failing
> that anything will do, as I mentioned in the original text?

You can obtain this by making two requests.

> >In a negotiation protocol, the client states what it is ready to accept and
> >mentions its order of preferences. Then the server chooses among the list.
> 
> But why this obsession with having the *server* make the decision?  

Please, avoid terms like "obsession".
 
> The *client* knows what it wants, so the client should make the decision, not 
> the server.  I'm just wondering here, is there some recommended design philosophy
> which I'm not aware of which says that the client can never make any decisions
> for itself but always has to leave it to others to make on its behalf?

Since you are wondering, a design philosophy about negotation has been
discussed at length in the CAT security working group and has lead to 
RFC 2478: 

The Simple and Protected GSS-API Negotiation Mechanism (December 1998)

Denis

> Peter.

Date: Mon, 04 Feb 2002 13:45:10 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
Sender: [email-masked]

Peter,

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

- Shouldn't this say that the ACs in question are to be conformant
  to [ACPROF]? Presumably this'd also mean that some fields in this
  spec have to obey the same profiling rules too, which sounds like
  a good idea.
- What's [ACMC] from november 2001? (Maybe its about to pop out?)
- The old LAAP protocol effectively allowed (the equivalent of) a regInfo
  value to select the "type" of AC to be produced - this draft seems to
  preclude that. Did I read it wrong or don't you think that's needed?
- Lastly, I never did come across a use case where a client would want
  to specify a really complicated AttrCertTemplate - have you? Absent
  that I'd have to say that this is maybe more complex than it needs
  to be.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Mon, 04 Feb 2002 14:24:36 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: Globally unique DNs - Why?
Sender: [email-masked]

Anders,

> Denis,
> Note that the word *global* is completely absent from the
> document you refer to.

...  hence why I wondered to which "animated" discussions you refer to, 
where the (wrong) statement would have been made.

We are in strong agreement.

Denis

> That DNs must be unique vs a certain CA is something that it is chrystal-
> clear, but that DNs must be (by themselves) be globally unique is as far I can see
> neither a requirement for general PKIX compliency, nor for QC compliency.
> 
> Anders
> 
> >> List,
> >> In certain, rather "animated" discussions, the statement is that an
> >> X509.v3 Subject DN (if specified) must be globally unique in order
> >> to be "conformant".
> 
> >Please read section  "4.1.2.6  Subject" page 24 from
> ><draft-ietf-pkix-new-part1-12.txt>
> 
> >The DN MUST be unique for each subject entity certified by the one CA
> >as defined by the issuer name field.
> 
> >Denis

Date: Mon, 04 Feb 2002 14:04:41 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Ambarish Malpani <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Ambarish,

Three remarks:

1) It would be interresting to say what happens in case an OCSP request
   is made after the end of the validity period of a certificate.

nextUpdate is currently defined as: "The time at or before which newer
information will be available about the status of *the* certificate".

If the certificate has expired, such information about *that* certificate
will never be available. Anyway, since the server does not necessarily have
access to the end-entity certificate, then it does not even know that the
certificate has expired.

A more appropriate definition about nextUpdate would be: "The time at or
before which newer status revocation information will be available from the
CA which has issued the certificate".

In addition, some guidance, in particular in the security considerations
section would be useful. Here is some tentative text:

An OCSP response does not indicate that the certificate is in its validity
interval. So, it is up to the clients to make sure that thisUpdate is
within the validity period of the end-entity certificate, which means that
clients MUST be able to parse the end-entity certificate to interpret the
validity period.

2) The "good" status has always been misleading. The text says: 

   The "good" state indicates that the certificate has not been revoked.

According to this definition, which is correct, an unambiguous status would
better be called: "not revoked" rather than "good".

3) A typo (suppress one "is"):

   It does not indicate that the certificate was ever issued,
   is or is in its validity interval.

should be changed into:

   It does not indicate that the certificate was ever issued,
   or is in its validity interval.

Denis

> Hi Guys,
>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
> 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
> 
> I hope we can get to the Draft Standard state before this IETF.
> 
> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>   ----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-07.txt
Date: Mon, 04 Feb 2002 07:21:53 -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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-07.txt
	Pages		: 
	Date		: 01-Feb-02
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about
the certificate, such as whether or not the certificate is valid, a
certification path to a trust anchor, and so on. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize their trust and policy management.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-07.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
Date: Mon, 04 Feb 2002 07:21:48 -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		: Attribute Certificate Request Message Format
	Author(s)	: P. Yee
	Filename	: draft-ietf-pkix-acrmf-00.txt
	Pages		: 9
	Date		: 01-Feb-02
	
The Certificate Request Message Format ([CRMF]) specifies a format
for requesting an X.509 public key certificate from a Certification
Authority (CA), possibly with assistance from an Local Registration
Authority (LRA).  This specification, ACRMF, is modeled on CRMF,
extending similar functionality to requests for X.509 attribute cer-
tificates from Attribute Authorities (AA), possibly via an Attribute
Registration Authority (ARA).

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 4 Feb 2002 00:48:41 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: "X.509": ;
Subject: X.509 working documents and defect reports on the server
Sender: [email-masked]

Hello all

The directory group will be meeting 27 February - 3 March 2002 in Geneva. We will be continuing looking at the enhancements proposed in the current working. It is on the server in Word and PDF at

  ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001Output/6N12093CertEnhancement3rdWD.pdf  and
  ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001Output/6N12093CertEnhancement3rdWD.doc

There are some unofficial, i.e. not yet submitted by standards organization, Canadian comments on the WD at

  ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002/Input/UnofficialCdnCommentOn509WD.pdf

The ballot on DTC-3 to the 4th (2000) edition of X.509/8584-8 has closed. The ballot comments, which will be resolved in Geneva, can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002/Input/WorkbookSovX.509DTC-3%284th%29.pdf

The DTC itself was previously announced.. It can be found in Word and PDF at

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

The ballot period on DTC-11 to the 3rd edition of X.509 and DTC-4 to the 4th edition will close 27 February 2002. We will resolve any ballot comments at the Geneva meeting. Those DTCs in Word and PDF can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12079X.509DTC-11%283rd%29.pdf
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12079X.509DTC-11%283rd%29.doc
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12078X.509DTC-4%284th%29.pdf
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12078X.509DTC-4%284th%29.doc

The Defect Reports being corrected by these DTCs can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_284.pdf
  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_285.pdf 
  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_286.pdf

A new Defect Report, DR 289, will be examined at the Geneva meeting. It can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_289.pdf

Comments on these documents should be sent to me and Sharon Boeyen

   hoyt

From: "Valery Smyslov" <[email-masked]>
Organization: TWS
To: Paul Hoffman / IMC <[email-masked]>, Dr S N Henson <[email-masked]>
Date: Mon, 4 Feb 2002 10:37:25 +0300
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
CC: Jean-Marc Desperrier <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2 Feb 02, at 0:35, Dr S N Henson wrote:

> Paul Hoffman / IMC wrote:
> >
> > Mallory does *not* need to change the public key in an OCID: he can
> > change any value in the certificate to get the right hash.
>
> I think the OCID would be the whole certificate including the digital
> signature. If the client checks the signature that would mean that any
> changes to the signed portion would require the signature to be
> recalculated.

I also think so.

> However as Peter pointed out if the unsigned portion of the certificate
> does not need to be DER encoded then all manner of ASN1 variations could
> be tried without the need to recalculate the signature. These could
> include...
>
> Changing some SEQUENCEs to use indefinite length constructed encoding.
>
> Modifying the encoding of the signature to use lots of constructed
> encoding variations. That by itself is enough if the decoder will
> tolerate it because the BER allow a BIT STRING to be partitioned into
> arbitrary chunks to arbitrary depths IIRC.

This problem is easy to avoid by requiring OCID hash to be always
produced only over DER-encoded certificates. In this case all other-
encoded certificates must be unambiguously reencoded (into DER)
before calculating OCID.

Regards,
Smyslov Valery.

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

Date: Sun, 03 Feb 2002 18:13:16 -0500
From: jim <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: Globally unique DNs - Why?
Sender: [email-masked]

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

Anders,
    The DN is used to find the person in the directory service so that the
electronic path to the recipient (the X.400 address) can be discerned.  The DDN
is used when checking to ensure that the certificate is valid, so I am not sure
that it has much to do with the name-space confusion, but it is used as part of
the validation process overall.  In that regard, globally unique DNs will
enhance the ability of the DDN to be completely accurate.
Jim

Anders Rundgren wrote:

>  Jim,Thanx for the information regarding DDNs!  Pardon an ignorant question:
> Does DDNs in effect set the name-spaces so that the aforementioned name-space
> contamination (Steve's Lotus Notes problem) does not occur?  I.e. there is
> actually no problem to solve using one of the method suggested?  Outside of
> the LDAP-world, I can testify that DN name-space confusion is indeed a serious
> problem, particularly in conjunction with non-directory-oriented
> applications.  It gets particularly bad when a single CA-cert/key is used to
> sign certificates belonging to different name-spaces and entity-types
> (commercial CAs usually don't do that, protecting them from this short-coming
> in the X509 system).  Using globally unique DNs there would be no naming
> problems, but as I tried to show, that may not be a very realistic
> option. Anders
>
>      From: jim
>      To: Anders Rundgren
>      Cc: Stephen Kent ; [email-masked]
>      Sent: Sunday, February 03, 2002 05:06
>      Subject: Re: Globally unique DNs - Why?
>       Point of clarification.  There is a difference between the
>      Distinguished Name (DN) and the Directory Distinguished Name (DDN).
>      The DN is the X.500 naming structure that goes from the root naming
>      structure of the directory to the outer branches and leaf entry for
>      an individual or role.  In LDAP directories, the structure is still
>      used, but from the individual or role moving up to the root entry.
>      The DDN, on the other hand, is the trail of authorizations for a
>      user moving from the issuing Certification Authority up to the root
>      issuing authority, be it a Policy Approving Authority in a very
>      hierarchical structure or the chief CA in a ring set up.  My
>      experience is that confusion of the two, DN and DDN, almost always
>      leads to lack of understanding of how the system needs to work.
>      Jim
>
>      Anders Rundgren wrote:
>
>     > Steve,
>     >
>     >      DNs are directory distinguished names, formally. the
>     >      directory tie-in implies that a DN sequence represents a
>     >      path in a directory tree structure. X.500 assumes a
>     >      universal tree, the DIT, and thus a DN consistent with
>     >      the semantics of X.500 would be globally unique. The DIT
>     >      is not a reality, and probably will never be, but one
>     >      can still note considerable advantages to DNs that are
>     >      globally unique.  No syntactic requirement in X.500
>     >      mandates such uniqueness, any more than it mandates
>     >      common sense re what directory attributes can be used in
>     >      forming a DN. It is certainly legitimate to construct
>     >      private directory trees that would not produce globally
>     >      unique DNs. but, experience with other name spaces
>     >      (e.g., Lotus Notes name spaces) has shown that often
>     >      what was assumed to be "private" ultimately becomes more
>     >      widely connected, and the collisions that arise due to a
>     >      lack of effort to attempt to ensure global uniqueness
>     >      come back to haunt system designers/administrators.
>     >
>     >      Steve
>     >
>     >      P.S.  I don't know from which end the example DN above
>     >      is intended to be read, but either direction yields a
>     >      pretty odd graph :-)
>     >
>     > Actually it was a little bit incorrect, as C=SE has recently been
>     > skipped, so now it is just CN=Name, serialNumber=nnnnn.  I.e. the
>     > DN became even more "private".  But one could also rightfully
>     > claim that a redundant DN item has been removed, as the
>     > certificate anyway requires knowledge of the regime (name-space)
>     > it was issued in. Although there are advantages with globally
>     > unique DNs, IMHO the number of drawbacks outnumber the
>     > advantages.  To name a few of those drawbacks:
>     >
>     >    * It probably requires something close to socialism to
>     >      establish such strictly conforming CAs
>     >    * It is in conflict with commercial disjunct name-spaces (e.g.
>     >      DUNS, VISA etc.)
>     >    * It may expose information that you not want to have in public
>     >    * And last but not least, it leads to a fragile ID-structure,
>     >      as the global schemes typically are based on a multitude of
>     >      attributes used to identify a subject, and if any of these
>     >      change, the link to the subject is broken.  This is in
>     >      contrast to my citizen-ID that is relevant as long as I stay
>     >      a Swedish citizen.  If the CA had been a commercial CA using
>     >      a private name-space, the ID could very well survive changes
>     >      in citizenship, name, and sex (there is a gender-tag in our
>     >      citizen-IDs so transsexuals find them less useful...).
>     >
>     > But as PKI except for web-server certificates, is just a long-time
>     > promise, both views are equally valid at this stage. I do though
>     > see a need for a possible PKIX work-item to support this multi
>     > name-space, "anarchistic" type of PKI, and that is a way for CAs
>     > to specify what private (or public), name-space their issued DNs
>     > belong to.  That would preferably be a URI, like for XML Schemas.
>     > Without such a specifier, we may indeed some day, get the Lotus
>     > Notes problem you referred to.  PIs is one way to achieve this,
>     > but I'm talking about a more neutral scheme as not everyone likes
>     > PIs. cheers,Anders
>

--------------DED226EAC051AFF6F54925B2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Anders,
<br>&nbsp;&nbsp;&nbsp; The DN is used to find the person in the directory
service so that the electronic path to the recipient (the X.400 address)
can be discerned.&nbsp; The DDN is used when checking to ensure that the
certificate is valid, so I am not sure that it has much to do with the
name-space confusion, but it is used as part of the validation process
overall.&nbsp; In that regard, globally unique DNs will enhance the ability
of the DDN to be completely accurate.
<br>Jim
<p>Anders Rundgren wrote:
<blockquote TYPE=CITE>&nbsp;<font face="Arial"><font size=-1>Jim,</font></font><font face="Arial"><font size=-1>Thanx
for the information regarding DDNs!&nbsp; Pardon an ignorant question:
Does DDNs in effect set the name-spaces so that the aforementioned name-space
contamination (Steve's Lotus Notes problem) does not occur?&nbsp; I.e.
there is actually no problem to solve using one of the method suggested?&nbsp;
Outside of the LDAP-world, I can testify that DN name-space confusion is
indeed a serious problem, particularly in conjunction with non-directory-oriented
applications.&nbsp; It gets particularly bad when a single CA-cert/key
is used to sign certificates belonging to different name-spaces and entity-types
(commercial CAs usually don't do that, protecting them from this short-coming
in the X509 system).&nbsp; Using globally unique DNs there would be no
naming problems, but as I tried to show, that may not be a very realistic
option.</font></font>&nbsp;<font face="Arial"><font size=-1>Anders</font></font>
<blockquote 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<div style="FONT: 10pt arial">----- Original Message -----</div>

<div 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><b>From:</b>
<a href="mailto:[email-masked]" title="[email-masked]">jim</a></div>

<div style="FONT: 10pt arial"><b>To:</b> <a href="mailto:[email-masked]" title="[email-masked]">Anders
Rundgren</a></div>

<div style="FONT: 10pt arial"><b>Cc:</b> <a href="mailto:[email-masked]" title="[email-masked]">Stephen
Kent</a> ; <a href="mailto:[email-masked]" title="[email-masked]">[email-masked]</a></div>

<div style="FONT: 10pt arial"><b>Sent:</b> Sunday, February 03, 2002 05:06</div>

<div style="FONT: 10pt arial"><b>Subject:</b> Re: Globally unique DNs -
Why?</div>
&nbsp;Point of clarification.&nbsp; There is a difference between the Distinguished
Name (DN) and the Directory Distinguished Name (DDN).&nbsp; The DN is the
X.500 naming structure that goes from the root naming structure of the
directory to the outer branches and leaf entry for an individual or role.&nbsp;
In LDAP directories, the structure is still used, but from the individual
or role moving up to the root entry.&nbsp; The DDN, on the other hand,
is the trail of authorizations for a user moving from the issuing Certification
Authority up to the root issuing authority, be it a Policy Approving Authority
in a very hierarchical structure or the chief CA in a ring set up.&nbsp;
My experience is that confusion of the two, DN and DDN, almost always leads
to lack of understanding of how the system needs to work.
<br>Jim
<p>Anders Rundgren wrote:
<blockquote TYPE="CITE"><style type=text/css></style>
<font face="Arial"><font size=-1>Steve,</font></font>
<blockquote style="MARGIN-RIGHT: 0px"><font face="Arial"><font color="#008080"><font size=-1>DNs
are directory distinguished names, formally. the directory tie-in implies
that a DN sequence represents a path in a directory tree structure. X.500
assumes a universal tree, the DIT, and thus a DN consistent with the semantics
of X.500 would be globally unique. The DIT is not a reality, and probably
will never be, but one can still note considerable advantages to DNs that
are globally unique.&nbsp; No syntactic requirement in X.500 mandates such
uniqueness, any more than it mandates common sense re what directory attributes
can be used in forming a DN. It is certainly legitimate to construct private
directory trees that would not produce globally unique DNs. but, experience
with other name spaces (e.g., Lotus Notes name spaces) has shown that often
what was assumed to be "private" ultimately becomes more widely connected,
and the collisions that arise due to a lack of effort to attempt to ensure
global uniqueness come back to haunt system designers/administrators.</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>Steve</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>P.S.&nbsp; I
don't know from which end the example DN above is intended to be read,
but either direction yields a pretty odd graph :-)</font></font></font></blockquote>
<font face="Arial"><font size=-1>Actually it was a little bit incorrect,
as C=SE has recently been skipped, so now it is just CN=<i>Name</i>, serialNumber=<i>nnnnn.&nbsp;
I.e. the DN became even more "private".&nbsp; </i>But one could also rightfully
claim that a <i>redundant </i>DN item has been removed, as the certificate
anyway requires knowledge of the regime (name-space) it was issued in.</font></font>
<font face="Arial"><font size=-1>Although there are advantages with globally
unique DNs, IMHO the number of drawbacks outnumber the advantages.&nbsp;
To name a few of those drawbacks:</font></font>
<ul>
<li>
<font face="Arial"><font size=-1>It probably requires something close to
socialism to establish such strictly conforming CAs</font></font></li>

<li>
<font face="Arial"><font size=-1>It is in conflict with commercial disjunct
name-spaces (e.g. DUNS, VISA etc.)</font></font></li>

<li>
<font face="Arial"><font size=-1>It may expose information that you not
want to have in public</font></font></li>

<li>
<font face="Arial"><font size=-1>And last but not least, it leads to a
<i>fragile </i>ID-structure, as the global schemes typically are based
on a multitude of attributes used to identify a subject, and if any of
these change, <i>the link to the subject is broken</i>.&nbsp; This is in
contrast to my citizen-ID that is relevant as long as I stay a Swedish
citizen.&nbsp; If the CA had been a commercial CA using a private name-space,
the ID could very well survive changes in citizenship, name, and sex (there
is a gender-tag in our citizen-IDs so transsexuals find them less useful...).</font></font></li>
</ul>
<font face="Arial"><font size=-1>But as PKI except for web-server certificates,
is just a long-time promise, <i>both views are equally valid at this stage</i>.
I do though see a need for a possible PKIX work-item to support this multi
name-space, "anarchistic" type of PKI, and that is a way for CAs to specify
what private (or public), name-space their issued DNs belong to.&nbsp;
That would preferably be a URI, like for <i>XML Schemas.&nbsp; Without
such a specifier, we may indeed some day, get the Lotus Notes problem you
referred to</i>.&nbsp; PIs is one way to achieve this, but I'm talking
about a more neutral scheme as not everyone likes PIs.</font></font>&nbsp;<font face="Arial"><font size=-1>cheers,</font></font><font face="Arial"><font size=-1>Anders</font></font></blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------DED226EAC051AFF6F54925B2--

From: "Anders Rundgren" <[email-masked]>
To: "jim" <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: Re: Globally unique DNs - Why?
Date: Sun, 3 Feb 2002 07:38:06 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Jim,
Thanx for the information regarding DDNs!  Pardon an ignorant question: =
Does DDNs in effect set the name-spaces so that the aforementioned =
name-space contamination (Steve's Lotus Notes problem) does not occur?  =
I.e. there is actually no problem to solve using one of the method =
suggested?  Outside of the LDAP-world, I can testify that DN name-space =
confusion is indeed a serious problem, particularly in conjunction with =
non-directory-oriented applications.  It gets particularly bad when a =
single CA-cert/key is used to sign certificates belonging to different =
name-spaces and entity-types (commercial CAs usually don't do that, =
protecting them from this short-coming in the X509 system).  Using =
globally unique DNs there would be no naming problems, but as I tried to =
show, that may not be a very realistic option.

Anders
  ----- Original Message -----=20
  From: jim=20
  To: Anders Rundgren=20
  Cc: Stephen Kent ; [email-masked]=20
  Sent: Sunday, February 03, 2002 05:06
  Subject: Re: Globally unique DNs - Why?

  Point of clarification.  There is a difference between the =
Distinguished Name (DN) and the Directory Distinguished Name (DDN).  The =
DN is the X.500 naming structure that goes from the root naming =
structure of the directory to the outer branches and leaf entry for an =
individual or role.  In LDAP directories, the structure is still used, =
but from the individual or role moving up to the root entry.  The DDN, =
on the other hand, is the trail of authorizations for a user moving from =
the issuing Certification Authority up to the root issuing authority, be =
it a Policy Approving Authority in a very hierarchical structure or the =
chief CA in a ring set up.  My experience is that confusion of the two, =
DN and DDN, almost always leads to lack of understanding of how the =
system needs to work.=20
  Jim=20
  Anders Rundgren wrote:=20

    Steve,=20
      DNs are directory distinguished names, formally. the directory =
tie-in implies that a DN sequence represents a path in a directory tree =
structure. X.500 assumes a universal tree, the DIT, and thus a DN =
consistent with the semantics of X.500 would be globally unique. The DIT =
is not a reality, and probably will never be, but one can still note =
considerable advantages to DNs that are globally unique.  No syntactic =
requirement in X.500 mandates such uniqueness, any more than it mandates =
common sense re what directory attributes can be used in forming a DN. =
It is certainly legitimate to construct private directory trees that =
would not produce globally unique DNs. but, experience with other name =
spaces (e.g., Lotus Notes name spaces) has shown that often what was =
assumed to be "private" ultimately becomes more widely connected, and =
the collisions that arise due to a lack of effort to attempt to ensure =
global uniqueness come back to haunt system designers/administrators.=20
      Steve=20

      P.S.  I don't know from which end the example DN above is intended =
to be read, but either direction yields a pretty odd graph :-)

    Actually it was a little bit incorrect, as C=3DSE has recently been =
skipped, so now it is just CN=3DName, serialNumber=3Dnnnnn.  I.e. the DN =
became even more "private".  But one could also rightfully claim that a =
redundant DN item has been removed, as the certificate anyway requires =
knowledge of the regime (name-space) it was issued in. Although there =
are advantages with globally unique DNs, IMHO the number of drawbacks =
outnumber the advantages.  To name a few of those drawbacks:=20
      a.. It probably requires something close to socialism to establish =
such strictly conforming CAs=20
      b.. It is in conflict with commercial disjunct name-spaces (e.g. =
DUNS, VISA etc.)=20
      c.. It may expose information that you not want to have in public=20
      d.. And last but not least, it leads to a fragile ID-structure, as =
the global schemes typically are based on a multitude of attributes used =
to identify a subject, and if any of these change, the link to the =
subject is broken.  This is in contrast to my citizen-ID that is =
relevant as long as I stay a Swedish citizen.  If the CA had been a =
commercial CA using a private name-space, the ID could very well survive =
changes in citizenship, name, and sex (there is a gender-tag in our =
citizen-IDs so transsexuals find them less useful...).=20
    But as PKI except for web-server certificates, is just a long-time =
promise, both views are equally valid at this stage. I do though see a =
need for a possible PKIX work-item to support this multi name-space, =
"anarchistic" type of PKI, and that is a way for CAs to specify what =
private (or public), name-space their issued DNs belong to.  That would =
preferably be a URI, like for XML Schemas.  Without such a specifier, we =
may indeed some day, get the Lotus Notes problem you referred to.  PIs =
is one way to achieve this, but I'm talking about a more neutral scheme =
as not everyone likes PIs.

    cheers,
    Anders

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Jim,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanx for the information regarding =
DDNs!&nbsp;=20
Pardon an ignorant question: Does DDNs in effect set the name-spaces so =
that the=20
aforementioned name-space contamination&nbsp;(Steve's Lotus Notes =
problem) does=20
not occur?&nbsp; I.e. there is&nbsp;actually no problem to solve using =
one=20
of&nbsp;the method suggested?&nbsp; Outside of the LDAP-world, I can =
testify=20
that DN name-space confusion is indeed a serious problem, particularly =
in=20
conjunction with non-directory-oriented applications.&nbsp; It gets =
particularly=20
bad when a single CA-cert/key is used to sign certificates belonging to=20
different name-spaces and entity-types (commercial CAs usually don't do =
that,=20
protecting them&nbsp;from this short-coming in the X509 system).&nbsp; =
Using=20
globally unique DNs there would be no naming problems, but as I tried to =

show,&nbsp;that may not be a very realistic option.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[email-masked]" =
title=[email-masked]>jim</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[email-masked]" =
title=[email-masked]>Anders=20
  Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Stephen Kent</A> ; <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, February 03, 2002 =

  05:06</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Globally unique =
DNs -=20
  Why?</DIV>
  <DIV><BR></DIV>Point of clarification.&nbsp; There is a difference =
between the=20
  Distinguished Name (DN) and the Directory Distinguished Name =
(DDN).&nbsp; The=20
  DN is the X.500 naming structure that goes from the root naming =
structure of=20
  the directory to the outer branches and leaf entry for an individual =
or=20
  role.&nbsp; In LDAP directories, the structure is still used, but from =
the=20
  individual or role moving up to the root entry.&nbsp; The DDN, on the =
other=20
  hand, is the trail of authorizations for a user moving from the =
issuing=20
  Certification Authority up to the root issuing authority, be it a =
Policy=20
  Approving Authority in a very hierarchical structure or the chief CA =
in a ring=20
  set up.&nbsp; My experience is that confusion of the two, DN and DDN, =
almost=20
  always leads to lack of understanding of how the system needs to work. =
<BR>Jim=20

  <P>Anders Rundgren wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">
    <STYLE type=3Dtext/css></STYLE>
    <FONT face=3DArial><FONT size=3D-1>Steve,</FONT></FONT>=20
    <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"><FONT face=3DArial><FONT=20
      color=3D#008080><FONT size=3D-1>DNs are directory distinguished =
names,=20
      formally. the directory tie-in implies that a DN sequence =
represents a=20
      path in a directory tree structure. X.500 assumes a universal =
tree, the=20
      DIT, and thus a DN consistent with the semantics of X.500 would be =

      globally unique. The DIT is not a reality, and probably will never =
be, but=20
      one can still note considerable advantages to DNs that are =
globally=20
      unique.&nbsp; No syntactic requirement in X.500 mandates such =
uniqueness,=20
      any more than it mandates common sense re what directory =
attributes can be=20
      used in forming a DN. It is certainly legitimate to construct =
private=20
      directory trees that would not produce globally unique DNs. but,=20
      experience with other name spaces (e.g., Lotus Notes name spaces) =
has=20
      shown that often what was assumed to be "private" ultimately =
becomes more=20
      widely connected, and the collisions that arise due to a lack of =
effort to=20
      attempt to ensure global uniqueness come back to haunt system=20
      designers/administrators.</FONT></FONT></FONT>=20
      <P><FONT face=3DArial><FONT color=3D#008080><FONT=20
      size=3D-1>Steve</FONT></FONT></FONT>=20
      <P><FONT face=3DArial><FONT color=3D#008080><FONT =
size=3D-1>P.S.&nbsp; I don't=20
      know from which end the example DN above is intended to be read, =
but=20
      either direction yields a pretty odd graph=20
    :-)</FONT></FONT></FONT></P></BLOCKQUOTE><FONT face=3DArial><FONT=20
    size=3D-1>Actually it was a little bit incorrect, as C=3DSE has =
recently been=20
    skipped, so now it is just CN=3D<I>Name</I>, =
serialNumber=3D<I>nnnnn.&nbsp; I.e.=20
    the DN became even more "private".&nbsp; </I>But one could also =
rightfully=20
    claim that a <I>redundant </I>DN item has been removed, as the =
certificate=20
    anyway requires knowledge of the regime (name-space) it was issued=20
    in.</FONT></FONT>&nbsp;<FONT face=3DArial><FONT size=3D-1>Although =
there are=20
    advantages with globally unique DNs, IMHO the number of drawbacks =
outnumber=20
    the advantages.&nbsp; To name a few of those =
drawbacks:</FONT></FONT>=20
    <UL>
      <LI><FONT face=3DArial><FONT size=3D-1>It probably requires =
something close to=20
      socialism to establish such strictly conforming CAs</FONT></FONT>=20
      <LI><FONT face=3DArial><FONT size=3D-1>It is in conflict with =
commercial=20
      disjunct name-spaces (e.g. DUNS, VISA etc.)</FONT></FONT>=20
      <LI><FONT face=3DArial><FONT size=3D-1>It may expose information =
that you not=20
      want to have in public</FONT></FONT>=20
      <LI><FONT face=3DArial><FONT size=3D-1>And last but not least, it =
leads to a=20
      <I>fragile </I>ID-structure, as the global schemes typically are =
based on=20
      a multitude of attributes used to identify a subject, and if any =
of these=20
      change, <I>the link to the subject is broken</I>.&nbsp; This is in =

      contrast to my citizen-ID that is relevant as long as I stay a =
Swedish=20
      citizen.&nbsp; If the CA had been a commercial CA using a private=20
      name-space, the ID could very well survive changes in citizenship, =
name,=20
      and sex (there is a gender-tag in our citizen-IDs so transsexuals =
find=20
      them less useful...).</FONT></FONT> </LI></UL>
    <DIV><FONT face=3DArial><FONT size=3D-1>But as PKI except for =
web-server=20
    certificates, is just a long-time promise, <I>both views are equally =
valid=20
    at this stage</I>. I do though see a need for a possible PKIX =
work-item to=20
    support this multi name-space, "anarchistic" type of PKI, and that =
is a way=20
    for CAs to specify what private (or public), name-space their issued =
DNs=20
    belong to.&nbsp; That would preferably be a URI, like for <I>XML=20
    Schemas.&nbsp; Without such a specifier, we may indeed some day, get =
the=20
    Lotus Notes problem you referred to</I>.&nbsp; PIs is one way to =
achieve=20
    this, but I'm talking about a more neutral scheme as not everyone =
likes=20
    PIs.</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>cheers,</FONT></FONT><FONT=20
    face=3DArial><FONT size=3D-1></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT=20
size=3D-1>Anders</FONT></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HT=
ML>

------=_NextPart_000_0016_01C1AC85.B7FFFF80--

Date: Sun, 3 Feb 2002 18:46:57 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>>To some extent, although you'd need to allow anyPolicy to allow the client to
>>specify that if it can't get an exact match, anything will do.
>
>If anything will do, then the client does not need to request any specific
>policy.

And how does this help if the client wants one of a set of policies, but failing
that anything will do, as I mentioned in the original text?

>In a negotiation protocol, the client states what it is ready to accept and
>mentions its order of preferences. Then the server chooses among the list.

But why this obsession with having the *server* make the decision?  The
*client* knows what it wants, so the client should make the decision, not the
server.  I'm just wondering here, is there some recommended design philosophy
which I'm not aware of which says that the client can never make any decisions
for itself but always has to leave it to others to make on its behalf?

Peter.

Date: Sat, 02 Feb 2002 23:06:37 -0500
From: jim <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Globally unique DNs - Why?
Sender: [email-masked]

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

Point of clarification.  There is a difference between the Distinguished Name
(DN) and the Directory Distinguished Name (DDN).  The DN is the X.500 naming
structure that goes from the root naming structure of the directory to the outer
branches and leaf entry for an individual or role.  In LDAP directories, the
structure is still used, but from the individual or role moving up to the root
entry.  The DDN, on the other hand, is the trail of authorizations for a user
moving from the issuing Certification Authority up to the root issuing
authority, be it a Policy Approving Authority in a very hierarchical structure
or the chief CA in a ring set up.  My experience is that confusion of the two,
DN and DDN, almost always leads to lack of understanding of how the system needs
to work.
Jim

Anders Rundgren wrote:

> Steve,
>
>      DNs are directory distinguished names, formally. the directory
>      tie-in implies that a DN sequence represents a path in a directory
>      tree structure. X.500 assumes a universal tree, the DIT, and thus a
>      DN consistent with the semantics of X.500 would be globally unique.
>      The DIT is not a reality, and probably will never be, but one can
>      still note considerable advantages to DNs that are globally unique.
>      No syntactic requirement in X.500 mandates such uniqueness, any more
>      than it mandates common sense re what directory attributes can be
>      used in forming a DN. It is certainly legitimate to construct
>      private directory trees that would not produce globally unique DNs.
>      but, experience with other name spaces (e.g., Lotus Notes name
>      spaces) has shown that often what was assumed to be "private"
>      ultimately becomes more widely connected, and the collisions that
>      arise due to a lack of effort to attempt to ensure global uniqueness
>      come back to haunt system designers/administrators.
>
>      Steve
>
>      P.S.  I don't know from which end the example DN above is intended
>      to be read, but either direction yields a pretty odd graph :-)
>
> Actually it was a little bit incorrect, as C=SE has recently been skipped, so
> now it is just CN=Name, serialNumber=nnnnn.  I.e. the DN became even more
> "private".  But one could also rightfully claim that a redundant DN item has
> been removed, as the certificate anyway requires knowledge of the regime
> (name-space) it was issued in. Although there are advantages with globally
> unique DNs, IMHO the number of drawbacks outnumber the advantages.  To name a
> few of those drawbacks:
>
>    * It probably requires something close to socialism to establish such
>      strictly conforming CAs
>    * It is in conflict with commercial disjunct name-spaces (e.g. DUNS, VISA
>      etc.)
>    * It may expose information that you not want to have in public
>    * And last but not least, it leads to a fragile ID-structure, as the global
>      schemes typically are based on a multitude of attributes used to identify
>      a subject, and if any of these change, the link to the subject is
>      broken.  This is in contrast to my citizen-ID that is relevant as long as
>      I stay a Swedish citizen.  If the CA had been a commercial CA using a
>      private name-space, the ID could very well survive changes in
>      citizenship, name, and sex (there is a gender-tag in our citizen-IDs so
>      transsexuals find them less useful...).
>
> But as PKI except for web-server certificates, is just a long-time promise,
> both views are equally valid at this stage. I do though see a need for a
> possible PKIX work-item to support this multi name-space, "anarchistic" type
> of PKI, and that is a way for CAs to specify what private (or public),
> name-space their issued DNs belong to.  That would preferably be a URI, like
> for XML Schemas.  Without such a specifier, we may indeed some day, get the
> Lotus Notes problem you referred to.  PIs is one way to achieve this, but I'm
> talking about a more neutral scheme as not everyone likes PIs. cheers,Anders

--------------C5C009F38AE20A6DD84D7857
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Point of clarification.&nbsp; There is a difference between the Distinguished
Name (DN) and the Directory Distinguished Name (DDN).&nbsp; The DN is the
X.500 naming structure that goes from the root naming structure of the
directory to the outer branches and leaf entry for an individual or role.&nbsp;
In LDAP directories, the structure is still used, but from the individual
or role moving up to the root entry.&nbsp; The DDN, on the other hand,
is the trail of authorizations for a user moving from the issuing Certification
Authority up to the root issuing authority, be it a Policy Approving Authority
in a very hierarchical structure or the chief CA in a ring set up.&nbsp;
My experience is that confusion of the two, DN and DDN, almost always leads
to lack of understanding of how the system needs to work.
<br>Jim
<p>Anders Rundgren wrote:
<blockquote TYPE=CITE><style type=text/css></style>
<font face="Arial"><font size=-1>Steve,</font></font>
<blockquote style="MARGIN-RIGHT: 0px"><font face="Arial"><font color="#008080"><font size=-1>DNs
are directory distinguished names, formally. the directory tie-in implies
that a DN sequence represents a path in a directory tree structure. X.500
assumes a universal tree, the DIT, and thus a DN consistent with the semantics
of X.500 would be globally unique. The DIT is not a reality, and probably
will never be, but one can still note considerable advantages to DNs that
are globally unique.&nbsp; No syntactic requirement in X.500 mandates such
uniqueness, any more than it mandates common sense re what directory attributes
can be used in forming a DN. It is certainly legitimate to construct private
directory trees that would not produce globally unique DNs. but, experience
with other name spaces (e.g., Lotus Notes name spaces) has shown that often
what was assumed to be "private" ultimately becomes more widely connected,
and the collisions that arise due to a lack of effort to attempt to ensure
global uniqueness come back to haunt system designers/administrators.</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>Steve</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>P.S.&nbsp; I
don't know from which end the example DN above is intended to be read,
but either direction yields a pretty odd graph :-)</font></font></font></blockquote>
<font face="Arial"><font size=-1>Actually it was a little bit incorrect,
as C=SE has recently been skipped, so now it is just CN=<i>Name</i>, serialNumber=<i>nnnnn.&nbsp;
I.e. the DN became even more "private".&nbsp; </i>But one could also rightfully
claim that a <i>redundant </i>DN item has been removed, as the certificate
anyway requires knowledge of the regime (name-space) it was issued in.</font></font>&nbsp;<font face="Arial"><font size=-1>Although
there are advantages with globally unique DNs, IMHO the number of drawbacks
outnumber the advantages.&nbsp; To name a few of those drawbacks:</font></font>
<ul>
<li>
<font face="Arial"><font size=-1>It probably requires something close to
socialism to establish such strictly conforming CAs</font></font></li>

<li>
<font face="Arial"><font size=-1>It is in conflict with commercial disjunct
name-spaces (e.g. DUNS, VISA etc.)</font></font></li>

<li>
<font face="Arial"><font size=-1>It may expose information that you not
want to have in public</font></font></li>

<li>
<font face="Arial"><font size=-1>And last but not least, it leads to a
<i>fragile </i>ID-structure, as the global schemes typically are based
on a multitude of attributes used to identify a subject, and if any of
these change, <i>the link to the subject is broken</i>.&nbsp; This is in
contrast to my citizen-ID that is relevant as long as I stay a Swedish
citizen.&nbsp; If the CA had been a commercial CA using a private name-space,
the ID could very well survive changes in citizenship, name, and sex (there
is a gender-tag in our citizen-IDs so transsexuals find them less useful...).</font></font></li>
</ul>
<font face="Arial"><font size=-1>But as PKI except for web-server certificates,
is just a long-time promise, <i>both views are equally valid at this stage</i>.
I do though see a need for a possible PKIX work-item to support this multi
name-space, "anarchistic" type of PKI, and that is a way for CAs to specify
what private (or public), name-space their issued DNs belong to.&nbsp;
That would preferably be a URI, like for <i>XML Schemas.&nbsp; Without
such a specifier, we may indeed some day, get the Lotus Notes problem you
referred to</i>.&nbsp; PIs is one way to achieve this, but I'm talking
about a more neutral scheme as not everyone likes PIs.</font></font>&nbsp;<font face="Arial"><font size=-1>cheers,</font></font><font face="Arial"><font size=-1>Anders</font></font></blockquote>

</body>
</html>

--------------C5C009F38AE20A6DD84D7857--

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Globally unique DNs - Why?
Date: Sat, 2 Feb 2002 14:16:41 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C1ABF4.3C530C10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: Globally unique DNs - Why?Steve,
  DNs are directory distinguished names, formally. the directory tie-in =
implies that a DN sequence represents a path in a directory tree =
structure. X.500 assumes a universal tree, the DIT, and thus a DN =
consistent with the semantics of X.500 would be globally unique. The DIT =
is not a reality, and probably will never be, but one can still note =
considerable advantages to DNs that are globally unique.  No syntactic =
requirement in X.500 mandates such uniqueness, any more than it mandates =
common sense re what directory attributes can be used in forming a DN. =
It is certainly legitimate to construct private directory trees that =
would not produce globally unique DNs. but, experience with other name =
spaces (e.g., Lotus Notes name spaces) has shown that often what was =
assumed to be "private" ultimately becomes more widely connected, and =
the collisions that arise due to a lack of effort to attempt to ensure =
global uniqueness come back to haunt system designers/administrators.

  Steve

  P.S.  I don't know from which end the example DN above is intended to =
be read, but either direction yields a pretty odd graph :-)
Actually it was a little bit incorrect, as C=3DSE has recently been =
skipped, so now it is just CN=3DName, serialNumber=3Dnnnnn.  I.e. the DN =
became even more "private".  But one could also rightfully claim that a =
redundant DN item has been removed, as the certificate anyway requires =
knowledge of the regime (name-space) it was issued in.

Although there are advantages with globally unique DNs, IMHO the number =
of drawbacks outnumber the advantages.  To name a few of those =
drawbacks:
  a.. It probably requires something close to socialism to establish =
such strictly conforming CAs
  b.. It is in conflict with commercial disjunct name-spaces (e.g. DUNS, =
VISA etc.)
  c.. It may expose information that you not want to have in public
  d.. And last but not least, it leads to a fragile ID-structure, as the =
global schemes typically are based on a multitude of attributes used to =
identify a subject, and if any of these change, the link to the subject =
is broken.  This is in contrast to my citizen-ID that is relevant as =
long as I stay a Swedish citizen.  If the CA had been a commercial CA =
using a private name-space, the ID could very well survive changes in =
citizenship, name, and sex (there is a gender-tag in our citizen-IDs so =
transsexuals find them less useful...).
But as PKI except for web-server certificates, is just a long-time =
promise, both views are equally valid at this stage. I do though see a =
need for a possible PKIX work-item to support this multi name-space, =
"anarchistic" type of PKI, and that is a way for CAs to specify what =
private (or public), name-space their issued DNs belong to.  That would =
preferably be a URI, like for XML Schemas.  Without such a specifier, we =
may indeed some day, get the Lotus Notes problem you referred to.  PIs =
is one way to achieve this, but I'm talking about a more neutral scheme =
as not everyone likes PIs.

cheers,
Anders

------=_NextPart_000_000B_01C1ABF4.3C530C10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Globally unique DNs - Why?</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<STYLE type=3Dtext/css></STYLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY background=3D"" bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Steve,</FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT color=3D#008080 face=3DArial size=3D2>DNs are directory =
distinguished=20
  names, formally. the directory tie-in implies that a DN sequence =
represents a=20
  path in a directory tree structure. X.500 assumes a universal tree, =
the DIT,=20
  and thus a DN consistent with the semantics of X.500 would be globally =
unique.=20
  The DIT is not a reality, and probably will never be, but one can =
still note=20
  considerable advantages to DNs that are globally unique.&nbsp; No =
syntactic=20
  requirement in X.500 mandates such uniqueness, any more than it =
mandates=20
  common sense re what directory attributes can be used in forming a DN. =
It is=20
  certainly legitimate to construct private directory trees that would =
not=20
  produce globally unique DNs. but, experience with other name spaces =
(e.g.,=20
  Lotus Notes name spaces) has shown that often what was assumed to be =
"private"=20
  ultimately becomes more widely connected, and the collisions that =
arise due to=20
  a lack of effort to attempt to ensure global uniqueness come back to =
haunt=20
  system designers/administrators.<BR><BR>Steve<BR><BR>P.S.&nbsp; I =
don't know=20
  from which end the example DN above is intended to be read, but either =

  direction yields a pretty odd graph :-)</FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>Actually it was a little bit incorrect, =
as C=3DSE has=20
recently been skipped, so now it is just CN=3D<EM>Name</EM>,=20
serialNumber=3D<EM>nnnnn.&nbsp; I.e. the DN&nbsp;became even=20
more&nbsp;"private".&nbsp; </EM>But one could also rightfully claim that =
a=20
<EM>redundant </EM>DN item&nbsp;has been removed, as the certificate =
anyway=20
requires knowledge of the regime (name-space) it was issued =
in.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Although there are&nbsp;advantages with =
globally=20
unique DNs, IMHO&nbsp;the number of drawbacks outnumber the =
advantages.&nbsp; To=20
name a few of those drawbacks:</FONT></DIV>
<UL>
  <LI><FONT face=3DArial size=3D2>It probably requires something close =
to socialism=20
  to establish such strictly conforming CAs</FONT></LI>
  <LI><FONT face=3DArial size=3D2>It is in conflict with&nbsp;commercial =
disjunct=20
  name-spaces (e.g. DUNS, VISA etc.)</FONT></LI>
  <LI><FONT face=3DArial size=3D2>It may expose information that you not =
want to=20
  have in public</FONT></LI>
  <LI><FONT face=3DArial size=3D2>And last but not least, it leads to a =
<EM>fragile=20
  </EM>ID-structure, as the global schemes typically are based on a =
multitude of=20
  attributes used to identify a subject, and if any of these change, =
<EM>the=20
  link to the subject is broken</EM>.&nbsp; This is in contrast to my =
citizen-ID=20
  that is relevant as long as I stay a Swedish citizen.&nbsp; If the CA =
had been=20
  a commercial CA using a private name-space, the ID could very well =
survive=20
  changes in citizenship,&nbsp;name, and sex (there is a gender-tag in =
our=20
  citizen-IDs so transsexuals find them less =
useful...).</FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2>But as PKI except for web-server =
certificates, is=20
just a long-time promise, <EM>both views are equally valid at this=20
stage</EM>.&nbsp;I do though see a need for a possible PKIX work-item to =
support=20
this multi name-space, "anarchistic" type of PKI, and that is a way for =
CAs to=20
specify what private (or public), name-space their issued DNs belong =
to.&nbsp;=20
That would preferably be a URI, like for <EM>XML =
Schemas.&nbsp;&nbsp;Without=20
such a specifier, we may indeed some day, get the Lotus Notes problem =
you=20
referred to</EM>.&nbsp; PIs is one way to achieve this, but I'm talking =
about a=20
more neutral scheme as not everyone likes PIs.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>cheers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01C1ABF4.3C530C10--

Date: Sat, 02 Feb 2002 00:39:21 +0000
From: Dr S N Henson <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

Jean-Marc Desperrier wrote:
> 
> 
> Still a few remarks.
> Mallory does not  need a strong key.
> He only needs a key that's OK enough to be used in the RSA algorithm without
> fatal errors.
> That might mean he can speed up the generation process.
> 

As I indicated in another message the RSA key generation process can be
speeded up so that all that is needed is to look up primes from a large
table and calculate their product.

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

Date: Sat, 02 Feb 2002 00:35:39 +0000
From: Dr S N Henson <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> Mallory does *not* need to change the public key in an OCID: he can
> change any value in the certificate to get the right hash.
> 

I think the OCID would be the whole certificate including the digital
signature. If the client checks the signature that would mean that any
changes to the signed portion would require the signature to be
recalculated.

However as Peter pointed out if the unsigned portion of the certificate
does not need to be DER encoded then all manner of ASN1 variations could
be tried without the need to recalculate the signature. These could
include...

Changing some SEQUENCEs to use indefinite length constructed encoding.

Modifying the encoding of the signature to use lots of constructed
encoding variations. That by itself is enough if the decoder will
tolerate it because the BER allow a BIT STRING to be partitioned into
arbitrary chunks to arbitrary depths IIRC.

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

Date: Fri, 1 Feb 2002 16:07:25 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Globally unique DNs - Why?
Cc: <[email-masked]>
Sender: [email-masked]

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

At 5:27 PM +0100 2/1/02, Anders Rundgren wrote:
>List,
>In certain, rather "animated" discussions, the statement that an
>X509.v3 Subject DN (if specified) must be globally unique in order
>to be "conformant".
>
>In my view this is not the case.  Referring to my own "citizen-ID"
>with a DN like
>
>      CN=Anders Rundgren, C=SE, serialNumber=nnnnnnnnnnnnnn
>
>which indeed have been created by "PKIX-aware" people, I
>would not call that a globally unique name.
>
>It is unique within its own name-space which happens to be Swedish
>citizen numbers but without that knowledge it could equally well
>be a member certificate of a more obscure community.
>
>But, and that the important thing, it is still a globally unique name
>when using the CA as a name-space indicator.
>
>Anders Rundgren

DNs are directory distinguished names, formally. the directory tie-in 
implies that a DN sequence represents a path in a directory tree 
structure. X.500 assumes a universal tree, the DIT, and thus a DN 
consistent with the semantics of X.500 would be globally unique. The 
DIT is not a reality, and probably will never be, but one can still 
note considerable advantages to DNs that are globally unique.  No 
syntactic requirement in X.500 mandates such uniqueness, any more 
than it mandates common sense re what directory attributes can be 
used in forming a DN. It is certainly legitimate to construct private 
directory trees that would not produce globally unique DNs. but, 
experience with other name spaces (e.g., Lotus Notes name spaces) has 
shown that often what was assumed to be "private" ultimately becomes 
more widely connected, and the collisions that arise due to a lack of 
effort to attempt to ensure global uniqueness come back to haunt 
system designers/administrators.

Steve

P.S.  I don't know from which end the example DN above is intended to 
be read, but either direction yields a pretty odd graph :-)
--============_-1199524659==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Globally unique DNs - Why?</title></head><body>
<div>At 5:27 PM +0100 2/1/02, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>List,<br>
In certain, rather &quot;animated&quot; discussions, the statement
that an<br>
X509.v3 Subject DN (if specified) must be globally unique in order<br>
to be &quot;conformant&quot;.<br>
<br>
In my view this is not the case.&nbsp; Referring to my own
&quot;citizen-ID&quot;<br>
with a DN like<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; CN=Anders Rundgren, C=SE,
serialNumber=nnnnnnnnnnnnnn<br>
<br>
which indeed have been created by &quot;PKIX-aware&quot; people, I<br>
would not call that a globally unique name.<br>
<br>
It is unique within its own name-space which happens to be Swedish<br>
citizen numbers but without that knowledge it could equally well<br>
be a member certificate of a more obscure community.<br>
<br>
But, and that the important thing, it is still a globally unique
name<br>
when using the CA as a name-space indicator.<br>
<br>
Anders Rundgren</blockquote>
<div><br></div>
<div>DNs are<u> directory</u> distinguished names, formally. the
directory tie-in implies that a DN sequence represents a path in a
directory tree structure. X.500 assumes a universal tree, the DIT, and
thus a DN consistent with the semantics of X.500 would be globally
unique. The DIT is not a reality, and probably will never be, but one
can still note considerable advantages to DNs that are globally
unique.&nbsp; No syntactic requirement in X.500 mandates such
uniqueness, any more than it mandates common sense re what directory
attributes can be used in forming a DN. It is certainly legitimate to
construct private directory trees that would not produce globally
unique DNs. but, experience with other name spaces (e.g., Lotus Notes
name spaces) has shown that often what was assumed to be
&quot;private&quot; ultimately becomes more widely connected, and the
collisions that arise due to a lack of effort to attempt to ensure
global uniqueness come back to haunt system
designers/administrators.</div>
<div><br></div>
<div>Steve</div>
<div><br></div>
<div>P.S.&nbsp; I don't know from which end the example DN above is
intended to be read, but either direction yields a pretty odd graph
:-)</div>
</body>
</html>
--============_-1199524659==_ma============--

From: "Anders Rundgren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Globally unique DNs - Why?
Date: Fri, 1 Feb 2002 21:36:33 +0100
Sender: [email-masked]

Denis,
Note that the word *global* is completely absent from the
document you refer to.

That DNs must be unique vs a certain CA is something that it is chrystal-
clear, but that DNs must be (by themselves) be globally unique is as far I can see
neither a requirement for general PKIX compliency, nor for QC compliency.

Anders

>> List,
>> In certain, rather "animated" discussions, the statement is that an
>> X509.v3 Subject DN (if specified) must be globally unique in order
>> to be "conformant".

>Please read section  "4.1.2.6  Subject" page 24 from 
><draft-ietf-pkix-new-part1-12.txt>

>The DN MUST be unique for each subject entity certified by the one CA 
>as defined by the issuer name field.

>Denis

Date: Fri, 1 Feb 2002 11:24:06 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

At 8:01 PM +0100 2/1/02, Jean-Marc Desperrier wrote:
>Mallory does not  need a strong key.
>He only needs a key that's OK enough to be used in the RSA algorithm without
>fatal errors.
>That might mean he can speed up the generation process.

If so, such exploits would make Mallory's job easier. However, can 
creating 2^79 weak RSA public keys ever be faster than computing 2^79 
SHA-1 hashes over a small message? That is the balance between 
choosing OKID and OCID.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 01 Feb 2002 20:01:17 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

Paul Hoffman / IMC wrote:

> At 12:28 AM +0100 2/1/02, Jean-Marc Desperrier wrote:
> >Clearly  if finding a collision does not suffice for Mallory in the
> >first case,
> >but that he has to find a collision for valid data, in that case a
> >valid key, then
> >in the second case, he also has to find a collision for valid data,
> >therefore a
> >valid certificate.
> Mallory does *not* need to change the public key in an OCID: he can
> change any value in the certificate to get the right hash.

Right, my reasonning was wrong.

Still a few remarks.
Mallory does not  need a strong key.
He only needs a key that's OK enough to be used in the RSA algorithm without
fatal errors.
That might mean he can speed up the generation process.

If the value of the hash is cleverly calculated on the signature and excludes
non-signed parts, Mallory will have to sign the certificate before
calculating the hash.

This would have to be checked in details before being sure there's that much
speed difference between the two processes.

From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>
Subject: FW: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 19:50:54 +0100
Importance: Normal
Sender: [email-masked]

Thanks for the good work. I am looking forward to an OCSP Draft Standard.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ambarish Malpani
> Sent: Thursday, January 31, 2002 9:31 PM
> To: [email-masked]'
> Subject: Candidate for moving OCSP to a Draft Standard
>
>
>
> Hi Guys,
>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
>
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
>
> I hope we can get to the Draft Standard state before this IETF.
>
> Regards,
> Ambarish
>
>
> Appendix D. Changes
>
>    This section contains the differences in this document from RFC 2560
>
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 18:11:07 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

> 
> Peter Gutmann wrote:
> > 
> > What if the client prefers policy X, but will accept anything if that's not
> > available?  This is standard procedure for restaurants, libraries, ...
> > 
> The client doesn't request some specific policy just for the kicks. He
> needs the time stamp for proving something to someone. This someone will
> most likely have rules according which he verifies time stamps ("I
> expect time stamps to be signed by TSA X and issued under policy Y").
> Therefore, receiving time stamp with policy which may or may not be
> equal or similar to the one requested, is of little value to the
> time-stamping client. In addition, this makes the protocol more complex
> as the client must implement procedures for dealing with time stamps
> with funny and unexpected policy identifiers.

Nothing in the protocol forbids that the TSA changes a policy.
Thus, a client must be prepared to handle unacceptedPolicy.

If in this situation, the TSA would return a time stamp with
another policy, the client or the application can still throw 
it away as part of a default implementation and simulate an
unacceptedpolicy answer. I wouldn't call this is a very complex
procedure. 

Right now, a TSA is always forced to return unacceptedPolicy. 

I am not describing any particular case for which
the TSA would return another OID as part of a standard
behaviour of whatever kind of desirable or undesirable
negotiation protcol. 

> Margus

From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, "Ambarish Malpani" <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 18:01:48 +0100
Importance: Normal
Sender: [email-masked]

> The easiest way would be to delete the support of pre-computed
> responses or
> set a maximum limit in the standard. The basic question would
> first be: who
> is using pre-computed responses with which retention period in the cache ?
> If no-one is using it, then the solution is simple. :-)

Just to clarify: You can always replace the term "pre-computed responses"
with "cached responses". Please be aware of that before dropping support for
pre-computed responses. It is hard enough for caching Responders with the
current nonce-requirements: A client using a nonce will disallow caching on
the OCSP-Responder.

Having a setup like 10 Sub-CAs, each certifying 1000 servers for SSL or
1.000.000 users for S/MIME, this will easily result in 30.000 OCSP-req/min
per Sub-CA. This means that in the course of the chain-validation, the
root-Responder will get 5.000 OCSP-requests per second. Given that I will
place the root-Responder in a specially secured network-envirmonment these
figures will make caching/pre-computed responses an issue. Within this
scenario the possiblity of a client to disallow caching at the responder
(with sending a nonce that MUST be answered) is a network and production
problem. But as the RfC correctly states, not using nonces will leave the
somewhat problematic producedAt time as our last defense-line regarding
replay-attacks.

Please discuss this controversly as it will determine the usability of the
protocol.

ciao, Fl0

BTW: I agree to Denis suggestion to invert point 7. and 8.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.

Date: Fri, 01 Feb 2002 17:58:16 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: Globally unique DNs - Why?
Sender: [email-masked]

Anders,

> List,
> In certain, rather "animated" discussions, the statement that an
> X509.v3 Subject DN (if specified) must be globally unique in order
> to be "conformant".

Please read section  "4.1.2.6  Subject" page 24 from 
<draft-ietf-pkix-new-part1-12.txt>

The DN MUST be unique for each subject entity certified by the one CA 
as defined by the issuer name field.

Denis

> In my view this is not the case.  Referring to my own "citizen-ID"
> with a DN like
> 
>      CN=Anders Rundgren, C=SE, serialNumber=nnnnnnnnnnnnnn
> 
> which indeed have been created by "PKIX-aware" people, I
> would not call that a globally unique name.
> 
> It is unique within its own name-space which happens to be Swedish
> citizen numbers but without that knowledge it could equally well
> be a member certificate of a more obscure community.
> 
> But, and that the important thing, it is still a globally unique name
> when using the CA as a name-space indicator.
> 
> Anders Rundgren

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Globally unique DNs - Why?
Date: Fri, 1 Feb 2002 17:27:58 +0100
Sender: [email-masked]

List,
In certain, rather "animated" discussions, the statement that an
X509.v3 Subject DN (if specified) must be globally unique in order
to be "conformant".

In my view this is not the case.  Referring to my own "citizen-ID"
with a DN like

     CN=Anders Rundgren, C=SE, serialNumber=nnnnnnnnnnnnnn

which indeed have been created by "PKIX-aware" people, I
would not call that a globally unique name.

It is unique within its own name-space which happens to be Swedish
citizen numbers but without that knowledge it could equally well
be a member certificate of a more obscure community.

But, and that the important thing, it is still a globally unique name
when using the CA as a name-space indicator.

Anders Rundgren

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "IETF PKIX" <[email-masked]>
Subject: Re: TSP interop update
Date: Fri, 1 Feb 2002 08:05:56 -0800
Sender: [email-masked]

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 01, 2002 6:15 AM
Subject: Re: TSP interop update

>
> Peter,
>
> > Denis Pinkas <[email-masked]> writes:
> > >IF, I did say "IF", we go into that direction, then it would mean
changing the
> > >reqPolicy field in TimeStampReq by allowing a sequence of TSA policies
instead
> > >of a single policy.
> > >
> > >Would this fit the concern from Peter ?
> >
> > To some extent, although you'd need to allow anyPolicy to allow the
client to
> > specify that if it can't get an exact match, anything will do.
>
> If anything will do, then the client does not need to request any specific
> policy.
>
> :-)
>
> > Consider for
> > example electronic tax filing, in which I have to get my submission
timestamped
> > to prove I filed on time.

Bad model - the IRS and the other tax collection bureaus care only when they
claim they recieved the document and unless there is a "rush to the
Courthouse" going on there - you have nothing to say about it other than
"err uhhhh Thanks." In order to have any effect here the Tax Bureau would
have to need to acknowledge independantly that you had paid your taxes and
there is no such tax process that needs that today - so this TSP is really
useless in taxation processing models.

>> Before I submit the return to irs.gov I go to
> > time.gov and get my return stamped.

No - Wrong - What matters is when the IRS.GOV site responds that it got the
filing not what time you submitted it. Who cares what time you submitted it
if the network eats the filing it is still your responsibility.

> > Ideally I'd want it notarised under the
> > 2002 tax policy, or failing that the 2000 tax policy, or the general tax
> > policy, but if all else fails I can probably get it done under the
dog-license
> > policy because if it goes to court all that matters is that it's
timestamped.
> > If it was under any of the standard tax policies I wouldn't need to go
to
> > court, but the dog-license policy is always better than having nothing
at all.

The problem is that in this model there is assumed to be some agent between
you and the Tax Collector and that is just not how its being rolled out. The
Tax Bureaus are allowing people to tunnel into secured forms on their sites
and by that creating a session level connection to the transaction servers
and as this the only thing that is an issue is what time the server tells
you this filing was recieved - what time you submitted it is irrelevant in a
legal sense in most all instances.

> > However:
> >
> > It's still making the decision at the wrong place.  Instead of the
client being
> > able to decide what's acceptable, it now has to communicate more and
more state
> > information to the server and still ask the server to make the decision
for it.

This is feature creep because no real use model existed. All the Server
needs to be able to do is to "Create and Verify" tokens and that to
accomplish this it should have a verification service model built into the
client-side protocol to support the working within the cause of "Verifying
the individual externally provided data points" for the Marque to be
created.

> > It's turning into an uglier and uglier kludge because the client, who
should be
> > making the decision, is banned from doing so, so all it can do is throw
a
> > mountain of state at the server and ask it to make the decision for it.

yes but this is true becuase the WG as a whole refuses to do what is clearly
necessary, which is to setup a set of use models for the protocol.

> > In the
> > case of the tax-timestamping above I can easily encode this process at
the
> > client, but I have no idea how I'd communicate that decision-making
process to
> > the server.  The real solution, which is relatively straightforward, is
to
> > allow the client to device what it wants to accept, not to require the
server
> > to make the decision for it.
>
> In a negotiation protocol, the client states what it is ready to accept
and
> mentions its order of preferences. Then the server chooses among the list.
>
> Denis
>
> > Peter.
>

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "IETF IESG" <[email-masked]>, <[email-masked]>
Subject: PKIX reform issues - Was Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Date: Fri, 1 Feb 2002 07:20:38 -0800
Sender: [email-masked]

Paul

>
> Where in the document did it say this? CAs and non-CA self-signers
> are allowed to do whatever they want.

The sentence you are looking for is not in the document, or any document
that PKIX has produced. It is in fact in everything that this WG (PKIX) does
by virtue of the fact that PKIX refesues to put in place Working Models for
how to use its protocols and its management refuses to consider this as a
requirement to separating submitted projects and their work products from
those that would more rightly belong in the realm of the IRTF.

This is a critical realization because what it implies is that SO LITTLE OF
WHAT PKIX IS DOING WILL EVER GET USED  in the commercial world and likely
much of it really does belong in a PKI group under the IRTF and not here.

And by the way Dr. Stephen Kent - That is your responsibility as the Senior
Chair of the WG... yours and the rest of the management's fault - and once
again I suggest that you personally consider moving-on becuase of it and
letting some fresher blood get into PKIX management with Tim.

>
> >  which is indeed a restriction that is
> >    not acceptable.
>
> Agree; that's why it doesn't say it.
>
> >    So the document should be changed to consider the hash of the
certificate
> >    instead of only the hash of the public key (and of the algorithm
> >    identifier).
>
> You then make Mallory's job many orders of magnitude easier. Instead
> of having to create 2^79 key pairs, he only has to create 2^79 hashes
> looking for one that matches Alice's OKID. That doesn't seem like a
> good security choice, particularly because we can assume that it is
> more likely that people will work on hardware hash acceleration than
> they will on hardware key generation.
>
> >    If we do so, then the "protocol" will also be usable for any type of
> >    certificate, not only self-signed certificates.
>
> Correct, but at the cost of making the protocol much easier to break.
>
> >2) The abstract should rephrased as:
> >
> >    The Out-of-Band Key Identifier Protocol (OKID) is a user-friendly
> >    out-of-band way to install certificates.
>
> Disagree. This protocol does not install certificates. It helps with
> only one step of that process.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 16:16:28 +0100 (MET)
To: [email-masked]
Subject: RE: TSP interop update
Sender: [email-masked]

> Denis:
> >
> > IF, I did say "IF", we go into that direction, then it would
> > mean changing
> > the reqPolicy field in TimeStampReq by allowing a sequence of
> > TSA policies
> > instead of a single policy.
> >
> 
> why not to introduce in the request message an extension to express the
> ordered list containing the preferred policies?
> 
> This way, expressing which policy is preferred or requested could be a
> little more tricky, but it could achieve the task to preserve backward
> compatibility.
> 
> Gianluca
I support in pronciple Gianluca's approach, see below. But this
seems another discussion: 

Are we sure that we understand the meaning of SHOULD?

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It seems that on one side we have people that say that the
policy used by the service MUST be identical. 

Just allowing 'SHOULD' does not mean that any particular 
interpretation is attempted, any kind of conspiracy
between clients and TSA about a particular way to request a policy,
could be possible. 

The current spec forces the TSA to return unacceptablepolicy.
in this case a client implementation needs procedure to recover 
from this problem.  

Returning a timestamp with another policy does not mean that
the client MUST accept it. It can locally simply implement
logic to throw away the time stamp because it doesn't like it
and simulate that error. The behaviour for the rest of the
application would be identical. I don't see that this means
an enormous additional complexity for the client implementation. 

Well, yes, if the nasty TSA makes You pay for something that
You haven't requested, and then claims that the standard says
that are not required to return the exact policy, so You have
to pay .... :-) 

-----

I am not in favour to change any ASN1 syntax or add
an extension to start some sort of policy negotiation. As
indicated by Gianluca, extensions seem a better way:

Just proposing a list of OIDs doesn't seem sufficient to me, it
would be a first small hack. If at some time one would be
able to formalise policies as a combination of smaller
elements, then one might end up asking that:
Please use a policy that has feature A + feature B or
fetaure A + C + D etc. 

Peter

Date: Fri, 01 Feb 2002 16:15:22 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Olle Mulmo <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, [email-masked]
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Olle,

> I don't quite agree with Denis on assuming a few hours to be OK 
> in a general scheme. Clearly, the value of the maximum lag time 
> on the producedAt field in an OCSP response must be defined in 
> the Operational Requirements section of the CA's CPS -- to be 
> defined and thought of months (or at least a few hours...) 
> before the OCSP service is to come online.

The problem is that an OCSP client is a client from different OCSP 
servers, each one may have different Operational Requirements. 
Since unfortunately Operational Requirement of the CA's CPS are 
not machine readable, there is no way for a client to automatically 
adjust the timing according to each CA, unless clients work in 
a closed environment with CAs that they all know in advance.

Denis

> However, revoked is revoked is revoked: shouldn't a client 
> accept an OCSP response containing a SingleResponse with 
> (status=revoked and reasonCode!=onHold), even though 
> the producedAt field is long by gone?
> 
> Regards,
> 
> Olle
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, February 01, 2002 10:34 AM
> To: Ambarish Malpani
> Cc: [email-masked]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> Ambarish,,
> 
> > Hi Guys,
> 
> >     Here is a candidate for moving OCSP to a Draft Standard. There
> > are no changes in the bytes that go across the wire - basically all
> > clarifications.
> 
> > A list of all the changes between this document and RFC 2560 are
> > in Appendix D (reproduced here).
> 
> > I hope we can get to the Draft Standard state before this IETF.
> 
> I have the following remarks:
> 
> The current text states:
> 
>    7. The producedAt time in the response is sufficiently recent.
> 
>    8. If the request contained a nonce, the response must contain the
>       same nonce (see section 4.4.1).
> 
> If the nonce is used, then the value of the producedAt field does not matter
> anymore and no test needs to be made on it. So I would first propose to
> invert items 8 and 7.
> 
> Then it is questionable on how implementers can interpret what "sufficiently
> recent" means for the producedAt time and set a value (a few minutes, hours
> or days ?).
> 
> In fact if no pre-computed response were being used, this could simply be
> set to a few minutes.
> 
> If pre-computed responses are being used, setting it to a few minutes will
> probably lead to rejections.
> 
> This means that using pre-computed responses is a real problem, since this
> value cannot even be fixed but is even dependent upon each server supporting
> pre-computed responses.
> 
> The easiest way would be to delete the support of pre-computed responses or
> set a maximum limit in the standard. The basic question would first be: who
> is using pre-computed responses with which retention period in the cache ?
> If no-one is using it, then the solution is simple. :-)
> 
> In the following proposal, I have not yet "crossed the line".
> 
> Proposed rephrasing:
> 
> [Prior to accepting a signed response as valid, OCSP clients SHALL
>  confirm that:]
> 
>    7. If the request contained a nonce, the response contains the
>       same nonce (see section 4.4.1).
> 
>    8. If the request did not contained a nonce, the producedAt time
>       in the response is considered as "sufficiently recent".
>       This means computing the difference between the current time
>       and the producedAt time and then comparing it with a time
>       period that will be set to a few minutes, or to a few hours
>       in the case where the OCSP servers accessed by the client
>       are supporting pre-computed responses.
> 
>       Note: when pre-computed responses are being used by servers,
>       it may be hard for clients to set a single maximum common value.
> 
> Denis
> 
> 
> > Regards,
> > Ambarish
> >
> > Appendix D. Changes
> >
> >    This section contains the differences in this document from RFC 2560
> >
> >    - Mention Appendix D in Section 1 and added an appendix D.
> >    - Added a paragraph in Section 1 equating a client with a requestor and
> >      server with responder
> >    - Section 2.2 - clarified the explanation of good, revoked and unknown
> >    - Added Section 2.8 requiring clients and responders to support HTTP
> >    - Added a note at the end of section 3.2, which allows a client to
> >      accept a response that provides statuses for only some of the
> >      certificates requested.
> >    - Clarified the issuerKeyHash in Section 4.1.1
> >    - Added "DER encoding of the" in the third paragraph Section 4.1.2
> >    - Section 4.2.1 - clarified that the signature is on the DER encoding
> >      of tbsResponseData (and not its hash)
> >    - Section 4.2.1 - specified the use of the certs field in
> >      BasicOCSPResponse
> >    - Section 4.2.1 - clarified how you compute KeyHash when providing
> >      the ResponderID byKey.
> >    - Section 4.2.2.2 - removed an extra quote in point 3
> >    - Section 4.3 - Made RSA mandatory. Also changed the references to
> >      point to the appropriate documents. Added the references to the
> >      References section
> >    - Section 4.4.1 - Clarified that a nonce in the request MUST be
> >    - included in the response for the response to be trusted.
> >    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
> >      anybody does it. It is also unclear how a server would tell a
> >      client to ever use GET in the URL specified in the AIA
> >    - Add the module tag for the ASN.1 in OCSP
> >    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
> >      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
> >      ambiguity of whether the optional sequence may be present, but
> >      with 0 elements. This was done by definining a new element called
> >      Certificates, which is used. Look at the defintion of both
> >      Signature and BasicOCSPResponse.
> >    - Clarified the meaning of nextUpdate being absent (Section 2.4)
> >    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
> >      correct OID - id-kp-OCSPSigning
> >    - Clarified criteria for response acceptance (Section 3.2)
> >    - Added a line in Section 5 indicating that nonces can be used to
> >      prevent prevent attacks using replays of precomputed responses
> >    - Added a paragraph in Section 5 requiring nonces to be unique for
> >      replay protection
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> >   ----------------------------------------------------------------------------
> >                         Name: OCSP-draft-03.txt
> >    OCSP-draft-03.txt    Type: Plain Text (text/plain)
> >                     Encoding: quoted-printable

Date: Fri, 01 Feb 2002 16:13:52 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: [email-masked]
CC: "'Antonio Lioy'" <[email-masked]>, [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

Gianluca,

> > IF, I did say "IF", we go into that direction, then it would
> > mean changing
> > the reqPolicy field in TimeStampReq by allowing a sequence of
> > TSA policies
> > instead of a single policy.

> why not to introduce in the request message an extension to express the
> ordered list containing the preferred policies?

Before defining a solution, the first question is the following: 
is this feature really needed ?
 
> This way, expressing which policy is preferred or requested could be a
> little more tricky, but it could achieve the task to preserve backward
> compatibility.

Thenafter we may define a solution. I have the same concern that you have:
"backward compatibility". Making a sequence of policies is simpler but
incompatible with the current document, hence why I asked first the question
to implementers whether they would be ready or have have problems to make
such a change.

Adding a new extension is a solution that I would like to avoid, but would
achieve backward ASN.1 compatibility, with the burden of defining things
like what happens when the new extension is present but not reqPolicy, 
or when both are present. :-(

Once again, the first question is the following: 
is this feature really needed ?

I would like to hear opinions.

Denis

> Gianluca

Importance: Normal
Sensitivity: 
Subject: Re: draft-ietf-pkix-pi
To: Denis Pinkas <[email-masked]>
Cc: Massimiliano Pala <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Fri, 1 Feb 2002 10:04:46 -0500
Sender: [email-masked]

      Denis:

      I have only one independent comment on this.  In the current draft,
the identifier is a DN.  There is no restriction in the definition of the
AttributeTypeAndValue type which would prevent an attribute with type OCTET
STRING from being used within it, even though that's not very user-friendly
naming.  There is even provision made to do LDAP lookups for such things in
RFC 2253 section 2.4, although the DER tag and length get included in the
value format, and X.520 predefines an OCTET STRING exact match.  So all we
need to do is define an attribute name and OID with that matching rule.
      If you want to specify conversion to hex or base 64 instead, that's
fine with me.

            Tom Gindin

Denis Pinkas <[email-masked]> on 02/01/2002 09:27:55 AM

To:    Massimiliano Pala <[email-masked]>
cc:    [email-masked], Tom Gindin/Watson/IBM@IBMUS
Subject:    Re: draft-ietf-pkix-pi

Massimiliano,

Your e-mail was sent yesterday. You are quite impatient to get an anwser.

Some quick comments:

1) The type of permanent identifier being used should rather be either an
  OID or a "persistant URL" (for the XML world that uses persitant URLs).
  This would certainly please Tom Guidin, my co-editor. :-)

  The full text identifier (identifierDesc) you propose would be subject
  to collisions and does not add anything: Permanent Identifiers are not
  for human users but machines.

2) The novelty you propose is to allow the use of a hash of the value
  instead of the value itself, without a rational but one reason has been
  given by Roberto Opazo Gazmuri on January 30 about the case of Hong Kong.

  The hash can really hide the value if the value is long enough. It would
  be interresting first to provide some figures about how long it would
take
  to invert a hash value, e.g. for the Hong Kong Identifier (HKID) case.

Should the WG decide to support a hash of the value (in addtion to the
value
itself), we could avoid overloading the syntax by simply defining an OID
that tells that the value is the hash of, e.g., the HKID instead of the
value of the HKID itsef.

Denis

> Hi all,
>
> no comments about my previous message on the subject ??? All of them are
> to be thrown off or there is something worth discussing ?
>
> Let me know.
>
> Can we submit a new version of the draft with proposed changes included ?

Within the IETF the rule is to submit change proposals to the editors so
they can incorporate them in the documents. So you should not submit a full
new version of the draft, but you can certainly propose detailed changes,
as
you have already done.

Denis

> --
> C'you,
>         Massimiliano Pala
--o-------------------------------------------------------------------------

> Massimiliano Pala [OpenCA Project Manager]               madwolf at
cpan.org
>                                                        madwolf at
openca.org
> http://www.openca.org                             madwolf at
hackmasters.net
> http://openca.sourceforge.net                    Mobile: +39 (0)347 7222
365

Importance: Normal
Sensitivity: 
To: Massimiliano Pala <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Fri, 1 Feb 2002 09:55:00 -0500
Subject: Re: draft-ietf-pkix-pi
Sender: [email-masked]

--0__=0ABBE1C0DFC2715D8f9e8a93df938690918c0ABBE1C0DFC2715D
Content-type: text/plain; charset=us-ascii

      Massimiliano:

      I agree with Al's point about the hash (that a hash solely on ID
numbers is too weak to be very valuable).  Also, the type of identifierDesc
would probably be better as DirectoryString or PrintableString than as
Name, which is the type for a DN.
      Your point about what the CA is certifying is correct, of course.
However, it should be pointed out that cross-CA comparisons of PI's are
valid if both CA's do their jobs correctly, although responsibility for a
false match could not be determined by automated procedures.

            Tom Gindin

Massimiliano Pala <[email-masked]>@mail.imc.org on 01/31/2002
05:56:53 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    draft-ietf-pkix-pi

Hi all,

I have some points I'd like to highlight about the PI. Current comments are
made against the http://www.imc.org/draft-ietf-pkix-pi.

First of all some general considerations. My personal point on the PI is
that this should be used only within the subjectAltName ext. and this to
prevent the Subject DN from ever growing and keep as human readable as
possible. I know that there could be established policies following the
Subject DN's but I support this option.

Let's get through the draft in order.

I would change the paragraph:

<< A permanent identifier is a name assigned by an organization,
   unique within that organization, that singles out a particular
   individual from all other individuals.  A CA which includes such
   an identifier in a certificate is certifying that any different
   public key certificate containing that identifier refers to the
   same individual. >>

Adding a phrase to clearly state that the "public key certificate..."
is from the CA in subject, something like:

<< A permanent identifier is a name assigned by an organization,
   unique within that organization, that singles out a particular
   individual from all other individuals.  A CA which includes such
   an identifier in a certificate is certifying that any different
   public key certificate issued by that CA and containing that
   identifier refers to the same individual. >>

I would like to extend the structure of the PersonalIdentifier to
something like this:

   PermanentIdentifier ::=     SEQUENCE {
           assignerAuthority        GeneralName OPTIONAL,
           identifierDesc           Name,
           identifierValue          IdentifierValue }

   IdentifierValue ::= CHOICE {
           permanentId        [1]       Name,
         permanentIdHash      [2]       IDHash }

   PermanentIdHash ::= SEQUENCE {
           identifierHash         OCTET STRING,  --- original identifier's
Hash
         identifierHashAlgorithm  AlgorithmIdentifier }

(there can be errors as I am not a master in structure definition :-D )

This structure (if correct) could solve problems tied to different current
situations, indeed there is the possibility to hide the "real" assigned ID
using the hash value instead. Usage of the Hash instead of the "real" ID
is therefore clearly stated when used. (this could be required if the
original
value carries sensible data like date of birth, etc... ).

The identifierDesc field is used to give a text identifier of the id used,
i.e. "RUN" or "ABN", depending on the description adopted by the
assignerAuthority
(I am not sure if this could be coded using different techniques, if so,
please,
point it out - thanks).

I'd also change the word "responsible" when talking about the
assignerAuthority some paragraph behind: this to state that this field
carries an indication not directly stated by the assignerAuthority's
subject (it is no liable for the contents of the field).

It could also be simply stripped off, something like:

<< The assignerAuthority field of this attribute, when present,
   identifies the organization assigning the content of the identifier
   field. When the assignerAuthority field is missing, the assignee
   Authority is the CA itself and it is assumed  to be the issuer
   name of the certificate. >>

Some comments ? Denis ?

--

C'you,

      Massimiliano Pala

--o-------------------------------------------------------------------------

Massimiliano Pala [OpenCA Project Manager]               madwolf at
cpan.org
                                                       madwolf at
openca.org
http://www.openca.org                             madwolf at
hackmasters.net
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222
365

--0__=0ABBE1C0DFC2715D8f9e8a93df938690918c0ABBE1C0DFC2715D
Content-type: application/octet-stream; 
	name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-transfer-encoding: base64

--0__=0ABBE1C0DFC2715D8f9e8a93df938690918c0ABBE1C0DFC2715D--

From: "todd glassey" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Subject: Re: TSP interop update
Date: Fri, 1 Feb 2002 06:37:10 -0800
Sender: [email-masked]

Or perhaps a graphical use model needs to be constructed showing the
decision points in the protocol and its use - otherwise how could we really
be sure ? Adding a statement of use, intent and constraints - no one seems
to want to do this? Why?

Todd
----- Original Message -----
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 01, 2002 3:03 AM
Subject: Re: TSP interop update

>
> folks,
>
> May I remind that my intervention addressed the situation that
> there are several phrases 3161 regarding the Policy ID,
> one of them was changed to a MUST which seems to me
> having the effect that the three sentences are no longer
> consistent.
>
> If nobody agrees with me then I might take a break and
> a course in IETF English or else.
>
> If people agree that the three phrases need to be changed,
> then :
>
> I had expressed my preference of a solution.
>
> Note also that in earlier drafts the OID was a "PolicyInformation".
>
> Peter
>
>

Date: Fri, 01 Feb 2002 15:27:55 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Massimiliano Pala <[email-masked]>
CC: [email-masked], Tom Gindin <[email-masked]>
Subject: Re: draft-ietf-pkix-pi
Sender: [email-masked]

Massimiliano,

Your e-mail was sent yesterday. You are quite impatient to get an anwser.

Some quick comments:

1) The type of permanent identifier being used should rather be either an
  OID or a "persistant URL" (for the XML world that uses persitant URLs). 
  This would certainly please Tom Guidin, my co-editor. :-) 

  The full text identifier (identifierDesc) you propose would be subject 
  to collisions and does not add anything: Permanent Identifiers are not 
  for human users but machines.

2) The novelty you propose is to allow the use of a hash of the value
  instead of the value itself, without a rational but one reason has been
  given by Roberto Opazo Gazmuri on January 30 about the case of Hong Kong.

  The hash can really hide the value if the value is long enough. It would 
  be interresting first to provide some figures about how long it would take
  to invert a hash value, e.g. for the Hong Kong Identifier (HKID) case.

Should the WG decide to support a hash of the value (in addtion to the value
itself), we could avoid overloading the syntax by simply defining an OID
that tells that the value is the hash of, e.g., the HKID instead of the 
value of the HKID itsef.

Denis  

> Hi all,
> 
> no comments about my previous message on the subject ??? All of them are
> to be thrown off or there is something worth discussing ?
> 
> Let me know.
> 
> Can we submit a new version of the draft with proposed changes included ?

Within the IETF the rule is to submit change proposals to the editors so
they can incorporate them in the documents. So you should not submit a full
new version of the draft, but you can certainly propose detailed changes, as
you have already done. 

Denis

> --
> 
> C'you,
> 
>         Massimiliano Pala
> 
> --o-------------------------------------------------------------------------
> Massimiliano Pala [OpenCA Project Manager]               madwolf at cpan.org
>                                                        madwolf at openca.org
> http://www.openca.org                             madwolf at hackmasters.net
> http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

Date: Fri, 01 Feb 2002 15:15:51 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

Peter,

> Denis Pinkas <[email-masked]> writes:
> >IF, I did say "IF", we go into that direction, then it would mean changing the
> >reqPolicy field in TimeStampReq by allowing a sequence of TSA policies instead
> >of a single policy.
> >
> >Would this fit the concern from Peter ?
> 
> To some extent, although you'd need to allow anyPolicy to allow the client to
> specify that if it can't get an exact match, anything will do.  

If anything will do, then the client does not need to request any specific
policy. 

:-)

> Consider for
> example electronic tax filing, in which I have to get my submission timestamped
> to prove I filed on time.  Before I submit the return to irs.gov I go to
> time.gov and get my return stamped.  Ideally I'd want it notarised under the
> 2002 tax policy, or failing that the 2000 tax policy, or the general tax
> policy, but if all else fails I can probably get it done under the dog-license
> policy because if it goes to court all that matters is that it's timestamped.
> If it was under any of the standard tax policies I wouldn't need to go to
> court, but the dog-license policy is always better than having nothing at all.
> 
> However:
> 
> It's still making the decision at the wrong place.  Instead of the client being
> able to decide what's acceptable, it now has to communicate more and more state
> information to the server and still ask the server to make the decision for it.
> It's turning into an uglier and uglier kludge because the client, who should be
> making the decision, is banned from doing so, so all it can do is throw a
> mountain of state at the server and ask it to make the decision for it.  In the
> case of the tax-timestamping above I can easily encode this process at the
> client, but I have no idea how I'd communicate that decision-making process to
> the server.  The real solution, which is relatively straightforward, is to
> allow the client to device what it wants to accept, not to require the server
> to make the decision for it.

In a negotiation protocol, the client states what it is ready to accept and
mentions its order of preferences. Then the server chooses among the list.

Denis
 
> Peter.

content-class: urn:content-classes:message
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 15:14:58 +0100
From: "Olle Mulmo" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Ambarish Malpani" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I don't quite agree with Denis on assuming a few hours to be OK in a general scheme. Clearly, the value of the maximum lag time on the producedAt field in an OCSP response must be defined in the Operational Requirements section of the CA's CPS -- to be defined and thought of months (or at least a few hours...) before the OCSP service is to come online.

However, revoked is revoked is revoked: shouldn't a client accept an OCSP response containing a SingleResponse with (status=revoked and reasonCode!=onHold), even though the producedAt field is long by gone?

Regards,

Olle

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, February 01, 2002 10:34 AM
To: Ambarish Malpani
Cc: [email-masked]'
Subject: Re: Candidate for moving OCSP to a Draft Standard

Ambarish,,

> Hi Guys,

>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
 
> I hope we can get to the Draft Standard state before this IETF.

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter 
anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.

Denis

> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>   ----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

Reply-To: <[email-masked]>
From: "Gianluca Ramunno" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Antonio Lioy'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: TSP interop update
Date: Fri, 1 Feb 2002 14:55:31 +0100
Importance: Normal
Sender: [email-masked]

Denis,

>
>
> IF, I did say "IF", we go into that direction, then it would
> mean changing
> the reqPolicy field in TimeStampReq by allowing a sequence of
> TSA policies
> instead of a single policy.
>

why not to introduce in the request message an extension to express the
ordered list containing the preferred policies?

This way, expressing which policy is preferred or requested could be a
little more tricky, but it could achieve the task to preserve backward
compatibility.

Gianluca

From: "Al Arsenault" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-pkix-pi
Date: Fri, 1 Feb 2002 08:21:46 -0500
Sender: [email-masked]

Massimiliano,

    A few comments on your proposal.  Comments are in-line, prefaced by my
initials, "AWA".

----- Original Message -----
From: "Massimiliano Pala" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 31, 2002 5:56 AM
Subject: draft-ietf-pkix-pi

> Hi all,
>
> I have some points I'd like to highlight about the PI. Current comments
are
> made against the http://www.imc.org/draft-ietf-pkix-pi.
>
> First of all some general considerations. My personal point on the PI is
> that this should be used only within the subjectAltName ext. and this to
> prevent the Subject DN from ever growing and keep as human readable as
> possible. I know that there could be established policies following the
> Subject DN's but I support this option.
>

AWA:  I agree with this.

> Let's get through the draft in order.
>
> I would change the paragraph:
>
> << A permanent identifier is a name assigned by an organization,
>    unique within that organization, that singles out a particular
>    individual from all other individuals.  A CA which includes such
>    an identifier in a certificate is certifying that any different
>    public key certificate containing that identifier refers to the
>    same individual. >>
>
>
> Adding a phrase to clearly state that the "public key certificate..."
> is from the CA in subject, something like:
>
> << A permanent identifier is a name assigned by an organization,
>    unique within that organization, that singles out a particular
>    individual from all other individuals.  A CA which includes such
>    an identifier in a certificate is certifying that any different
>    public key certificate issued by that CA and containing that
>    identifier refers to the same individual. >>
>

AWA:  I agree.

> I would like to extend the structure of the PersonalIdentifier to
> something like this:
>
>    PermanentIdentifier ::=     SEQUENCE {
>            assignerAuthority        GeneralName OPTIONAL,
>            identifierDesc           Name,
>            identifierValue          IdentifierValue }
>
>    IdentifierValue ::= CHOICE {
>            permanentId [1]     Name,
>    permanentIdHash [2]     IDHash }
>
>    PermanentIdHash ::= SEQUENCE {
>            identifierHash     OCTET STRING,  --- original identifier's
Hash
>    identifierHashAlgorithm  AlgorithmIdentifier }
>
> (there can be errors as I am not a master in structure definition :-D )
>
> This structure (if correct) could solve problems tied to different current
> situations, indeed there is the possibility to hide the "real" assigned ID
> using the hash value instead. Usage of the Hash instead of the "real" ID
> is therefore clearly stated when used. (this could be required if the
original
> value carries sensible data like date of birth, etc... ).
>

AWA:  I don't know that we can/should necessarily define a particular
structure for this.  We've already seen on this list that a number of
different places have different formats and requirements for the uses of
PI's; it's not going to be easy to find a single structure that will fit
them all.

AWA:  The use of a hash to protect PI's that are supposed to be private data
is generally insufficient. The problem is that the PI space is generally not
that big; it's easy enough for an attacker to build a table of the hashes of
all possible PIs, and then pick the values out of the certificates.  For
example, in the US, the most likely PI would be the Social Security Number,
which consists of 9 digits.  So the total SSN space consists of (10 to the
9th) values, which means that hashing all possible SSNs represents only
about 30 bits worth of work. (I've been told, but don't know for a fact,
that the SSN space is actually smaller, because not all digits are
independent.  If that's the case, it's easier for the attacker.)

AWA: That's the reason for the scheme used in Hong Kong, that I pointed out
earlier.  If I understand correctly, there are only about 26 million unique
HKIDs.  One of the folks in our HK office told me that, several years ago,
they constructed the table of all possible hashed-HKID values on a 200-mHz
Pentium I machine, using not-fully-optimized code, in about 15 minutes.  It
clearly ruled out the use of a hash by itself to protect the data!

> The identifierDesc field is used to give a text identifier of the id used,
> i.e. "RUN" or "ABN", depending on the description adopted by the
> assignerAuthority
> (I am not sure if this could be coded using different techniques, if so,
please,
> point it out - thanks).
>
> I'd also change the word "responsible" when talking about the
> assignerAuthority some paragraph behind: this to state that this field
> carries an indication not directly stated by the assignerAuthority's
> subject (it is no liable for the contents of the field).
>
> It could also be simply stripped off, something like:
>
> << The assignerAuthority field of this attribute, when present,
>    identifies the organization assigning the content of the identifier
>    field. When the assignerAuthority field is missing, the assignee
>    Authority is the CA itself and it is assumed  to be the issuer
>    name of the certificate. >>
>
> Some comments ? Denis ?
>
> --
>
> C'you,
>
> Massimiliano Pala

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 07:15:38 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C1AB1A.28C67A40
Content-Type: text/plain

All:

Please note the following:

1.  producedAt will always be at or later than thisUpdate.

2.  The current RFC has a rule for thisUpdate with language similar to the
one proposed for thisUpdate.

Simple arithmetic tells me that if we want to caveat the producedAt rule, we
should have the same caveat for thisUpdate rule.

That said, I am happy with the language proposed by Ambarish for producedAt.

However, if the community feels that the language for producedAt should
change, then we should make even more of a change for thisUpdate language
(since thisUpdate is always earlier than producedAt).

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, February 01, 2002 4:34 AM
To: Ambarish Malpani
Cc: [email-masked]'
Subject: Re: Candidate for moving OCSP to a Draft Standard

Ambarish,,

> Hi Guys,

>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
 
> I hope we can get to the Draft Standard state before this IETF.

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter

anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.

Denis

> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>
----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

------_=_NextPart_001_01C1AB1A.28C67A40
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Candidate for moving OCSP to a Draft Standard</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All:</FONT>
</P>

<P><FONT SIZE=3D2>Please note the following:</FONT>
</P>

<P><FONT SIZE=3D2>1.&nbsp; producedAt will always be at or later than =
thisUpdate.</FONT>
</P>

<P><FONT SIZE=3D2>2.&nbsp; The current RFC has a rule for thisUpdate =
with language similar to the one proposed for thisUpdate.</FONT>
</P>

<P><FONT SIZE=3D2>Simple arithmetic tells me that if we want to caveat =
the producedAt rule, we should have the same caveat for thisUpdate =
rule.</FONT></P>

<P><FONT SIZE=3D2>That said, I am happy with the language proposed by =
Ambarish for producedAt.</FONT>
</P>

<P><FONT SIZE=3D2>However, if the community feels that the language for =
producedAt should change, then we should make even more of a change for =
thisUpdate language (since thisUpdate is always earlier than =
producedAt).</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, February 01, 2002 4:34 AM</FONT>
<BR><FONT SIZE=3D2>To: Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Candidate for moving OCSP to a Draft =
Standard</FONT>
</P>
<BR>
<BR>

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

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

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Here is a candidate for =
moving OCSP to a Draft Standard. There</FONT>
<BR><FONT SIZE=3D2>&gt; are no changes in the bytes that go across the =
wire - basically all</FONT>
<BR><FONT SIZE=3D2>&gt; clarifications.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; A list of all the changes between this document =
and RFC 2560 are</FONT>
<BR><FONT SIZE=3D2>&gt; in Appendix D (reproduced here).</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; I hope we can get to the Draft Standard state =
before this IETF.</FONT>
</P>

<P><FONT SIZE=3D2>I have the following remarks:</FONT>
</P>

<P><FONT SIZE=3D2>The current text states:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 7. The producedAt time in the response =
is sufficiently recent.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 8. If the request contained a nonce, the =
response must contain the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; same nonce (see =
section 4.4.1).</FONT>
</P>

<P><FONT SIZE=3D2>If the nonce is used, then the value of the =
producedAt field does not matter </FONT>
<BR><FONT SIZE=3D2>anymore and no test needs to be made on it. So I =
would first propose to </FONT>
<BR><FONT SIZE=3D2>invert items 8 and 7.</FONT>
</P>

<P><FONT SIZE=3D2>Then it is questionable on how implementers can =
interpret what &quot;sufficiently</FONT>
<BR><FONT SIZE=3D2>recent&quot; means for the producedAt time and set a =
value (a few minutes, hours </FONT>
<BR><FONT SIZE=3D2>or days ?).</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>In fact if no pre-computed response were being used, =
this could simply be</FONT>
<BR><FONT SIZE=3D2>set to a few minutes.</FONT>
</P>

<P><FONT SIZE=3D2>If pre-computed responses are being used, setting it =
to a few minutes will</FONT>
<BR><FONT SIZE=3D2>probably lead to rejections.</FONT>
</P>

<P><FONT SIZE=3D2>This means that using pre-computed responses is a =
real problem, since this</FONT>
<BR><FONT SIZE=3D2>value cannot even be fixed but is even dependent =
upon each server supporting</FONT>
<BR><FONT SIZE=3D2>pre-computed responses.</FONT>
</P>

<P><FONT SIZE=3D2>The easiest way would be to delete the support of =
pre-computed responses or</FONT>
<BR><FONT SIZE=3D2>set a maximum limit in the standard. The basic =
question would first be: who</FONT>
<BR><FONT SIZE=3D2>is using pre-computed responses with which retention =
period in the cache ?</FONT>
<BR><FONT SIZE=3D2>If no-one is using it, then the solution is simple. =
:-)</FONT>
</P>

<P><FONT SIZE=3D2>In the following proposal, I have not yet =
&quot;crossed the line&quot;.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Proposed rephrasing:</FONT>
</P>

<P><FONT SIZE=3D2>[Prior to accepting a signed response as valid, OCSP =
clients SHALL</FONT>
<BR><FONT SIZE=3D2>&nbsp;confirm that:]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 7. If the request contained a nonce, the =
response contains the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; same nonce (see =
section 4.4.1).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 8. If the request did not contained a =
nonce, the producedAt time </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the response is =
considered as &quot;sufficiently recent&quot;. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This means computing =
the difference between the current time </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the producedAt =
time and then comparing it with a time </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; period that will be =
set to a few minutes, or to a few hours </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the case where the =
OCSP servers accessed by the client </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are supporting =
pre-computed responses. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: when =
pre-computed responses are being used by servers,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it may be hard for =
clients to set a single maximum common value.</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Appendix D. Changes</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; This section contains the =
differences in this document from RFC 2560</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Mention Appendix D in =
Section 1 and added an appendix D.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a paragraph in =
Section 1 equating a client with a requestor and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; server with =
responder</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 2.2 - clarified the =
explanation of good, revoked and unknown</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added Section 2.8 requiring =
clients and responders to support HTTP</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a note at the end of =
section 3.2, which allows a client to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; accept a response =
that provides statuses for only some of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificates =
requested.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Clarified the issuerKeyHash =
in Section 4.1.1</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added &quot;DER encoding of =
the&quot; in the third paragraph Section 4.1.2</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.1 - clarified =
that the signature is on the DER encoding</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
tbsResponseData (and not its hash)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.1 - specified =
the use of the certs field in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
BasicOCSPResponse</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.1 - clarified =
how you compute KeyHash when providing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the ResponderID =
byKey.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.2.2 - removed =
an extra quote in point 3</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.3 - Made RSA =
mandatory. Also changed the references to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; point to the =
appropriate documents. Added the references to the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; References =
section</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.4.1 - Clarified =
that a nonce in the request MUST be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - included in the response =
for the response to be trusted.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Appendix A - A.1.1. - Got =
rid of support for GET - not sure that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; anybody does it. =
It is also unclear how a server would tell a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; client to ever =
use GET in the URL specified in the AIA</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Add the module tag for the =
ASN.1 in OCSP</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Made SEQUENCE OF =
Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Certificate =
OPTIONAL in the ASN.1 defintions. The avoids the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ambiguity of =
whether the optional sequence may be present, but</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with 0 elements. =
This was done by definining a new element called</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Certificates, =
which is used. Look at the defintion of both</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signature and =
BasicOCSPResponse.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Clarified the meaning of =
nextUpdate being absent (Section 2.4)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Fixed typo where we =
referred to id-ad-ocspSigning, to reflect the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; correct OID - =
id-kp-OCSPSigning</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Clarified criteria for =
response acceptance (Section 3.2)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a line in Section 5 =
indicating that nonces can be used to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; prevent prevent =
attacks using replays of precomputed responses</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a paragraph in =
Section 5 requiring nonces to be unique for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; replay =
protection</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; =
------------------------------------------------------------------------=
----</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; Name: OCSP-draft-03.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; OCSP-draft-03.txt&nbsp;&nbsp;&=
nbsp; Type: Plain Text (text/plain)</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Encoding: =
quoted-printable</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1AB1A.28C67A40--

Date: Fri, 01 Feb 2002 11:58:49 +0100
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: [email-masked]
Subject: Re: draft-ietf-pkix-pi
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Hi all,

no comments about my previous message on the subject ??? All of them are
to be thrown off or there is something worth discussing ?

Let me know.

Can we submit a new version of the draft with proposed changes included ?

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               madwolf at cpan.org
                                                       madwolf at openca.org
http://www.openca.org                             madwolf at hackmasters.net
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365
--------------ms00CF14B10D648459252D8621
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms00CF14B10D648459252D8621--

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 12:03:24 +0100 (MET)
To: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

folks,

May I remind that my intervention addressed the situation that
there are several phrases 3161 regarding the Policy ID,
one of them was changed to a MUST which seems to me 
having the effect that the three sentences are no longer
consistent. 

If nobody agrees with me then I might take a break and
a course in IETF English or else.

If people agree that the three phrases need to be changed,
then :

I had expressed my preference of a solution.

Note also that in earlier drafts the OID was a "PolicyInformation".

Peter

Date: Fri, 01 Feb 2002 10:40:02 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

Peter Gutmann wrote:
> Actually I think the main problem with this draft (which others have also
> alluded to indirectly) is that it's trying to do two things at once: Identify
> certs using a hash, and provide a way of encoding binary values as user-
> friendly keys.  I think it'd be better to split the two, create a universal
> user-friendly key-encoding RFC and then move the identifying-certs bit
> elsewhere.  The key-encoding is useful in lots of other places, for example
> I've been using it with CMP for enrolment details.

I kind of like this idea, since I might want to be able 
to do the equivalent trick in an xmldsig context where 
I'd (probably) be hashing over a ds:KeyInfo.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 11:37:32 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 
> Peter,
> 
> > >It is simmple: if a client requests a policy and if the server supports that
> > >policy, why should the server choose a different policy ? Just to annoy the
> > >client ?
> > 
> > What if the client prefers policy X, but will accept anything if that's not
> > available?  

Cl:      want something to eat but I am not very hungry.
service: in this case we propose You our small sandwich.
 
> Simple.
>  
> First exchange:  he asks for a given policy and does not get it.
> Second exchange: he does not use the optional field reqPolicy and 
>                  thus gets what the server has.

This doesn't work if the TSA supports more than one incompatible
policies. 

> 
> Denis 
> 
> > This is standard procedure for restaurants, libraries, ...
> > 
> > Twitchen: "We'll have the duck".
> > Fawlty: "Duck's off, sorry".
> > Twitchen: "We'll have the trifle then".
> > 
> > TSP however requires:
> > 
> > Twitchen: "We'll have the duck".
> > Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
> >          trying to run a TSA here. Have you any idea how much there is to do?
> >          Go away".
> > 
> > Ah, we have an RFC which standardises Fawlty Towers.
> > 
> > Peter.
> 

Date: Fri, 1 Feb 2002 23:22:38 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:
>IF, I did say "IF", we go into that direction, then it would mean changing the
>reqPolicy field in TimeStampReq by allowing a sequence of TSA policies instead
>of a single policy.
>
>Would this fit the concern from Peter ?

To some extent, although you'd need to allow anyPolicy to allow the client to
specify that if it can't get an exact match, anything will do.  Consider for
example electronic tax filing, in which I have to get my submission timestamped
to prove I filed on time.  Before I submit the return to irs.gov I go to
time.gov and get my return stamped.  Ideally I'd want it notarised under the
2002 tax policy, or failing that the 2000 tax policy, or the general tax
policy, but if all else fails I can probably get it done under the dog-license
policy because if it goes to court all that matters is that it's timestamped.
If it was under any of the standard tax policies I wouldn't need to go to
court, but the dog-license policy is always better than having nothing at all.

However:

It's still making the decision at the wrong place.  Instead of the client being
able to decide what's acceptable, it now has to communicate more and more state
information to the server and still ask the server to make the decision for it.
It's turning into an uglier and uglier kludge because the client, who should be
making the decision, is banned from doing so, so all it can do is throw a
mountain of state at the server and ask it to make the decision for it.  In the
case of the tax-timestamping above I can easily encode this process at the
client, but I have no idea how I'd communicate that decision-making process to
the server.  The real solution, which is relatively straightforward, is to
allow the client to device what it wants to accept, not to require the server
to make the decision for it.

Peter.

Date: Fri, 01 Feb 2002 10:33:31 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Ambarish Malpani <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
Sender: [email-masked]

Ambarish,,

> Hi Guys,

>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
 
> I hope we can get to the Draft Standard state before this IETF.

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter 
anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.

Denis

> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>   ----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

Date: Fri, 01 Feb 2002 09:54:10 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

Paul,

> At 5:11 PM +0100 1/31/02, Denis Pinkas wrote:
> >1) The current document addresses only the verification of self-signed
> >    certificates, but is subject to security attacks (i.e. substitution
> >    of self-signed certificates) because only the hash of the public key
> >    contained in the self-signed certificate is verified:
> 
> Correct. I have yet to hear of an interesting attack where Mallory
> has some good reason to substitute "Alice A" for "Alice B" on Bob's
> system when "Alice A" and "Alice B" are both self-signed.

We are talking of trust anchors. A self-signed certificate contains among
other things a validity period and naming constraints.

1) The validity period limits the duration of the trust anchor.

It is not mandatory to change the value of the public key when a self-signed
certificate is renewed. Hence a replay attack is possible by re-installing
the current self-signed certifiace instead of a new one.

2) Clients may install different self-signed certificates that contain
different naming constraints. If naming constraints are not part of the
hash, then substitution of trust anchors with different naming constraints
is possible.

So the requirement is to have the hash of the certificate, not simply 
the hash of the public key (and of the algorithm identifier).  

The question of the security comes just *after*.

As soon as a hash is truncated, the security is indeed lower. I let
cryptographers discuss this issue, since I am not a cryptographer. We might
consider different levels of security: the bigger the number of characters
being typed will be, the better the security will be.

Denis

> >  this would mandate
> >    that a CA is not allowed to issue more than one self-signed certificate
> >    with the same public key in it,
> 
> Where in the document did it say this? CAs and non-CA self-signers
> are allowed to do whatever they want.
> 
> >  which is indeed a restriction that is
> >    not acceptable.
> 
> Agree; that's why it doesn't say it.
> 
> >    So the document should be changed to consider the hash of the certificate
> >    instead of only the hash of the public key (and of the algorithm
> >    identifier).
> 
> You then make Mallory's job many orders of magnitude easier. Instead
> of having to create 2^79 key pairs, he only has to create 2^79 hashes
> looking for one that matches Alice's OKID. That doesn't seem like a
> good security choice, particularly because we can assume that it is
> more likely that people will work on hardware hash acceleration than
> they will on hardware key generation.
> 
> >    If we do so, then the "protocol" will also be usable for any type of
> >    certificate, not only self-signed certificates.
> 
> Correct, but at the cost of making the protocol much easier to break.
> 
> >2) The abstract should rephrased as:
> >
> >    The Out-of-Band Key Identifier Protocol (OKID) is a user-friendly
> >    out-of-band way to install certificates.
> 
> Disagree. This protocol does not install certificates. It helps with
> only one step of that process.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Fri, 01 Feb 2002 09:49:45 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Antonio Lioy <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

Antonio,

> Peter Gutmann wrote:
> >
> > Margus Freudenthal <[email-masked]> writes:
> >
> > >In addition, this makes the protocol more complex as the client must implement
> > >procedures for dealing with time stamps with funny and unexpected policy
> > >identifiers.
> >
> > It's far easier to compare the returned ID with a known-good set than to submit
> > a string of requests going down a list of acceptable policies trying to find
> > one the TSA won't reject.
 
> No, only the client knowns which are the acceptable policies to it,
> while the TSA issue a TST under one specific policy. So the client MUST
> send its list of acceptable policies, listed in order of preference, and
> the TSA MUST issue a TST with the policy of highest preference
> available, or MUST return an error "no acceptable policy here".

Your proposal is leading into a direction I am quite familiar with:
Negotiation (see RFC 2478 - The Simple and Protected GSS-API Negotiation
Mechanism).

IF, I did say "IF", we go into that direction, then it would mean changing
the reqPolicy field in TimeStampReq by allowing a sequence of TSA policies
instead of a single policy.

Would this fit the concern from Peter ?
What would be the opinion of the current implementers, and of the WG ?

Denis

> Antonio

Date: Fri, 01 Feb 2002 09:35:53 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

Peter,

> >It is simmple: if a client requests a policy and if the server supports that
> >policy, why should the server choose a different policy ? Just to annoy the
> >client ?
> 
> What if the client prefers policy X, but will accept anything if that's not
> available?  

Simple.
 
First exchange:  he asks for a given policy and does not get it.
Second exchange: he does not use the optional field reqPolicy and 
                 thus gets what the server has.

Denis 

> This is standard procedure for restaurants, libraries, ...
> 
> Twitchen: "We'll have the duck".
> Fawlty: "Duck's off, sorry".
> Twitchen: "We'll have the trifle then".
> 
> TSP however requires:
> 
> Twitchen: "We'll have the duck".
> Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
>          trying to run a TSA here. Have you any idea how much there is to do?
>          Go away".
> 
> Ah, we have an RFC which standardises Fawlty Towers.
> 
> Peter.

From: "Valery Smyslov" <[email-masked]>
Organization: TWS
To: Jean-Marc Desperrier <[email-masked]>, [email-masked], Paul Hoffman / IMC <[email-masked]>
Date: Fri, 1 Feb 2002 11:35:39 +0300
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

On 31 Jan 02, at 17:03, Paul Hoffman / IMC wrote:

Paul,

[...]

> We disagree here. Given Alice's OCID (it is now a cert ID, not a key
> ID), Mallory creates a template certificate with his own public key
> in it. In the template, he adds an extension that has an octet stream
> of length 10. He then cycles through all the combinations of 2^80
> values in the octet stream until the hash over the template
> certificate matches Alice's OCID, signs the cert, and is done.
>
> Mallory does *not* need to change the public key in an OCID: he can
> change any value in the certificate to get the right hash.

But doesn't he still need to sign certificate before hashing?
Clearly, signing is less computationly expensive than creating public
key, but it is still much more expensive than just hashing.

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

Regards,
Valery Smyslov.

Date: Fri, 01 Feb 2002 09:26:17 +0100
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

Peter Gutmann wrote:
> 
> Margus Freudenthal <[email-masked]> writes:
> 
> >In addition, this makes the protocol more complex as the client must implement
> >procedures for dealing with time stamps with funny and unexpected policy
> >identifiers.
> 
> It's far easier to compare the returned ID with a known-good set than to submit
> a string of requests going down a list of acceptable policies trying to find
> one the TSA won't reject.

No, only the client knowns which are the acceptable policies to it,
while the TSA issue a TST under one specific policy. So the client MUST
send its list of acceptable policies, listed in order of preference, and
the TSA MUST issue a TST with the policy of highest preference
available, or MUST return an error "no acceptable policy here".

Antonio

Date: Fri, 1 Feb 2002 21:17:44 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

Margus Freudenthal <[email-masked]> writes:

>In addition, this makes the protocol more complex as the client must implement
>procedures for dealing with time stamps with funny and unexpected policy
>identifiers.

It's far easier to compare the returned ID with a known-good set than to submit
a string of requests going down a list of acceptable policies trying to find
one the TSA won't reject.

Peter.