Subject: Re: Certificate Policy Standardization

From: [email-masked] (Peter Gutmann)
Date: Wed, 26 Nov 2003 23:55:41 +1300

Anders Rundgren <[email-masked]> writes:

>Policy OIDs might come handy to protect RPs from issuing authorities who
>might seek to alter their terms arbitrarily without necessarily providing
>notice to that effect. In practice, ambiguity over the exact content of
>applicable policy might render that CP unenforceable.

I've seen it used in exactly the opposite way.  If you look at the ToS for any
(well, most I guess, there might actually be some who don't try this) online
service providers (ISP, web/email hosting, online store, e-commerce site, etc
etc) they all say that they can change their ToS at any moment, with or
without notifying their customers, depending on how thorough their lawyers
are.  Yahoo spring to mind as a well-known web/email hosting example, every
now and then (the last time was within the last week or so) they change their
ToS to allow spamming of customers unless you go in and turn all the choices
off again, but since they don't have to notify you of the change most users
never find out about it until it's too late.

So what you do is define a policy OID that points to whatever the policy is
this week, and if you need to change anything you alter your policy, which
customers are expected to check by downloading it from an undocumented
location in an LDAP directory on a server in a locked filing cabinet in a
disused lavatory in the cellar with a sign on the door saying "Beware of the
Leopard", as explained in section 43, subsection 18, clause 4(a).13, paragraph
227.a of said policy.  The policy extension seems almost designed for this
use, it has provisions for specifying an OID and a means of pointing to the
policy of the week, which is just what you need.

The reason why this is approach is used is that if you changed your OID when
your policy changes, you'd have to re-issue all your certs, which no-one wants
to do.  So you define your policy to be a mutable object, push responsibility
for checking for changes onto the user in the standard manner, and you're set.

Peter.

---

From: [email-masked]
Date: Wed, 26 Nov 2003 13:41:30 +0000

> CA s/w is not equivalent to RP s/w.

Agreed

> Please tell me where I in the latest edition of Outlook Express (I'm
> indeed a daring guy...), can "tweak" the CA policy trust settings.
> In case you don't find the "knob", does this in your opinion mean
> that Microsoft is not standards-compliant w.r.t. policy-OIDs?

Not at all. Like I said, at present it is largely ignored. Reinforced
by it absence from such a widespread COTS application like Outlook
Express. You'd have to ask MS why it doesn't process it but having worked
quite closely with them in this area my guess is that they would argue
that there is no need to include a feature for which there is presently
no demand.

> Also please show me a single commercial CA that uses multiple
> CPs for a certain root.

Personally ? No, I could not.

Chris

---

From: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000

> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?

My experiences with so far 4 different PKI 'systems' are that
all of them could implement CP but only one did so out-of-the-box.
I feel very strongly that the vanilla deployment is one
that supports a homogeneous environment and does not take into
account interop with other PKIs. This is likely to be caused
by a number of factors including a desire to steer the end
user away from competitors, saving money in deploying unrequired
features and keeping the vanilla deployment as simple as possible
(if that is possible with PKI!!!). Given the current lack of
support for CP it does not surprise me that it is not part of
the vanilla deployment.

> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?

Differentiate between 'cannot' and 'do not'. I would be very
surprised if they all cannot but I am not surprised that they
all do not (if that makes sense). Application of CP is, as you
have already said, a function of RP s/w. Commercial CAs issue
certificates to anyone who wants them yet CP is function of
local, company policy. Why should a commercial CA issue certs
with my CP in them (unless I pay them to do so)? As I see it,
at present a commercial CA will issue a CP which says no more
than 'this is my CP'. Third party s/w has no reason to enforce
this CP because it is private to the CA. When apps become
more security aware I will expect to see them enforce CP issued
from the corporate CA or from other Xcert CAs mapped through
policyMap.

Don't ask me when this will happen, though :-)

Chris

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 28 Nov 2003 00:33:35 +1300

Stephen Kent <[email-masked]> writes:

>Policies could be created on an industry sector basis, for example. The IETF
>could publish the resulting policies and assign OIDs, but PKIX is not a
>suitable forum for the development of such policies.

So what you're saying is that this is an ecumenical matter?

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:42:05 +1300

Stephen Kent <[email-masked]> writes:

>For example, most certs used with IKE will not be subject to some attorney's
>advice, I suspect.

Actually now that you mention it one of the three classes of certs that were
going to be used in the situation I mentioned were IKE certs.  I think they
were going to subclass "doWhatISay" into "doWhatISayWithIKE",
"doWhatISayWithSSL", and "doWhatISayWithSMIMESigning"(not sure about the last
one, I have the paperwork downstairs but I'm too lazy to look it up).  All of
them were going to go through the full legal wringer.

Peter.

---

From: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000

Chris

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 05:59:48 +1300

Stephen Kent <[email-masked]> writes:

>one might ask why the most widely distributed product that claims to
>implement IPsec  (Windows) does not provide a user/administrator the ability
>to order SPD entries, as required by RFC 2401. The answer is that the
>implementors did not understand why this was an important (in the case of
>IPsec, a critical) aspect of the standard and so the implementors omitted an
>important management control.
>
>what one can learn from this an similar examples is that vendors are a very
>poor basis for determining the worth of a feature in a standard. 

Actually what I learn from this is that complex standards with often
incomprehensible requirements are just asking for trouble if they don't
include a rationale.  Even a single sentence explaining the background behind
the SPD entry ordering would have prevented this in a manner that no amount of
MUSTs/SHALLs ever can.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:36:04 +1300

Andreas Mitrakas <[email-masked]> writes:

>Especially so in some implementations in Europe where there is a direct link
>between the policy and the law under which certain certs like QC certs are
>issued.

The feeling was that digital signature legislation (following the UNCITRAL
model) is so vaguely worded that this wouldn't be a problem.  Qualified certs
are a bit more problematic, but that's only in Europe.

>A CP becomes part of the parties agreement and binding by means of e.g. a
>subscriber agreement. So it is not unthinkable albeit not necessarily
>desirable, that a courts might  scrutinise policies. --God forbid.

The feeling here was that a ToS-style policy might violate (at least NZ)
consumer protection legislation, however since a number of large organisations
relied on these types of agreements there would probably be a spirited defence
of them in court and/or existing case law upholding them.  See e.g Xtra
(Telecom NZ ISP) terms, which state:

  12. Changes to these Customer Terms

  We may change these Customer Terms by changing or removing existing terms,
  or by adding new ones. Changes may take the form of completely new terms.

  [Notification stuff snipped]

  A copy of our current terms is displayed on our Website. It is your
  responsibility to check these Customer Terms regularly (at least monthly)
  for any modifications or updates. You will be deemed to have accepted the
  changes to these Customer Terms and to have agreed to be bound by the
  revised Customer Terms if you continue to use and/or access the Services
  after the date that the changes are stated to be effective.

  We reserve the right to change any charges or Services, or any Separate
  Terms, at any time without notice. It is your responsibility to check all
  applicable Separate Terms regularly for any modifications or updates.

That's the sort of thing the "policy is what we say it is" that I mentioned
earlier was based on.  Just for reference, here's what Yahoo says:

  Yahoo! provides its service to you, subject to the following Terms of
  Service ("TOS"), which may be updated by us from time to time without notice
  to you. You can review the most current version of the TOS at any time at:
  http://docs.yahoo.com/info/terms/. 
  
  [Snippage]

  Yahoo! reserves the right at any time and from time to time to modify or
  discontinue, temporarily or permanently, the Service (or any part thereof)
  with or without notice. You agree that Yahoo! shall not be liable to you or
  to any third party for any modification, suspension or discontinuance of the
  Service.

The debate then went off on a tangent about whether a PKI was providing a
service of any value to a user (if it doesn't it's not covered by standard
consumer-protection law), and how you'd present that in court.

Disclaimer: IANAL, I just talk to them occasionally.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 07:14:10 +1300

Stephen Kent <[email-masked]> writes:

>Implementors of a technology ought (MUST/SHALL?) be competent in the
>technology that they are implementing. A standard like IPsec is not a "Secure
>Communication  Protocols for Dummies" document.

  The first thing one notices when looking at IPsec is that the documentation
  is very hard to understand. There is no overview or introduction, the reader
  has to assemble all the pieces and build an overview himself. This is a
  highly unsatisfactorily state of affairs; after all, the documentation is
  meant to convey information to the readers. We do not believe it is
  reasonable to expect anyone to learn IPsec from the IPsec documentation.
  Various parts of the IPsec documentation are very hard to read. For ex-
  ample, the ISAKMP specifications [MSST98] contain numerous errors, essential
  explanations are missing, and the document contradicts itself in various
  places.

  [...]
  
  None of the IPsec documentation provides any rationale for any of the
  choices that were made. Although this is somewhat less important than a
  clear statement of the goals, we nevertheless consider it crucial
  information. If a reviewer is to comment on the design (and RFCs are, after
  all, Requests For Comments), he should be told what each option was intended
  to achieve. Without any rationale, the reviewer is left to guess at it, and
  then review the design based on the guessed-at rationale.

  [...]
  
  In our opinion, IPsec is too complex to be secure. The design obviously
  tries to support many different situations with different options. We feel
  very strongly that the resulting system is well beyond the level of
  complexity that can be analysed or properly implemented with current method-
  ologies. Thus, no IPsec system will achieve the goal of providing a high
  level of security.

  [...]

  It is far too complex, and the complexity has lead to a large number of
  ambiguities, contradictions, inefficiencies, and weaknesses. It has been
  very hard work to perform any kind of security analysis; we do not feel that
  we fully understand the system, let alone have fully analyzed it.

Obviously non-dummies can't make much sense of it either.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 07:14:10 +1300

[...]

  [...]

  [...]

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:13:30 +1300

"Anders Rundgren" <[email-masked]> writes:

>1. Why does practically no shrink-wrap PKI-enabled software package support
>any kind of certificate policy settings?

Zero demand.  Heck, it wasn't too long ago that MS PKI software hardcoded the
Verisign policy into CryptoAPI, so that no matter what the actual policy was
in the cert, what was displayed was the Verisign policy.  That shows how much
attention people are paying to the policy stuff.

That doesn't mean that RPs don't use a policy-equivalent: The software is
configured - via trusted roots - to only accept certs from a given set of CAs
(Anders, that's the policy-configurability you asked for, it's just not called
that).  So the trusted-roots mechanism does what the policy extension is
supposed to do, and the policy extension becomes a legal self-defence
mechanism for the benefit of the CA.  This is an almost complete inversion of
what RFC 3280 thinks that the policy extension is meant for:

  Applications with specific policy requirements are expected to have a list
  of those policies which they will accept and to compare the policy OIDs in
  the certificate to that list.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:42:05 +1300

Peter.

---

From: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000

Chris

---

From: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000

Chris

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 05:59:48 +1300

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:42:05 +1300

Peter.

---

From: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000

Chris

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 07:14:10 +1300

[...]

  [...]

  [...]

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:36:04 +1300

[Snippage]

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:42:05 +1300

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:13:30 +1300

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:36:04 +1300

[Snippage]

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 07:14:10 +1300

[...]

  [...]

  [...]

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 29 Nov 2003 14:12:16 +1300

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:

>I'm not a lawyer and the terms are for sure used much differently in other
>countries. But I also guess that most ToS-style CPs would not withstand a
>court trial based on german AGB-Gesetz, the law regulating "Allgemeine 
>Gesch=E4ftsbedingungen" (similar to ToS).
>
>But since PKI did not hit the mass market yet a CA with such a ToS-style CP
>can assume that this risk is quite low. 
>
>Less RPs => less serious usage => less risks. ;-)

That was the feeling here too.  No-one knows what analysis (e.g.) Telecom's
lawyers went through to come up with their ToS, but certainly for PKI it was
felt that the stakes are so low that it's unlikely anyone will ever bother
testing the CP in court, just as with an ISP no-one will pursue a $100K test
case over a $29.95 account.  So it's not just what's legal, it's what you can
get away with, and since PKI is a legal gray area anyway the balance is
definitely skewed in favour of the large, well-funded incumbent applying
whatever terms they feel like, because any kind of legal challenge is going to
end up as an expensive, uncertain-outcome test case.

I know that there's been some legal analysis of the use of shared-key MACs in
situations where you'd normally expect a PKI to be used, and even though some
of the lawyers could immediately see that it wasn't secure, the feeling was
that the chances of it being successfully challenged in court were negligible.
This is at least in part because of signed (on paper) agreements assigning
responsibility (there are local variations on this, e.g. in the military you
can be ordered to accept the ToS just as they can order you to walk through a
minefield).

Banks got by with simple checksums for some decades without any major legal
problems...

Peter.

Date: Sat, 29 Nov 2003 14:12:16 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:

>I'm not a lawyer and the terms are for sure used much differently in other
>countries. But I also guess that most ToS-style CPs would not withstand a
>court trial based on german AGB-Gesetz, the law regulating "Allgemeine 
>Gesch=E4ftsbedingungen" (similar to ToS).
>
>But since PKI did not hit the mass market yet a CA with such a ToS-style CP
>can assume that this risk is quite low. 
>
>Less RPs => less serious usage => less risks. ;-)

That was the feeling here too.  No-one knows what analysis (e.g.) Telecom's
lawyers went through to come up with their ToS, but certainly for PKI it was
felt that the stakes are so low that it's unlikely anyone will ever bother
testing the CP in court, just as with an ISP no-one will pursue a $100K test
case over a $29.95 account.  So it's not just what's legal, it's what you can
get away with, and since PKI is a legal gray area anyway the balance is
definitely skewed in favour of the large, well-funded incumbent applying
whatever terms they feel like, because any kind of legal challenge is going to
end up as an expensive, uncertain-outcome test case.

I know that there's been some legal analysis of the use of shared-key MACs in
situations where you'd normally expect a PKI to be used, and even though some
of the lawyers could immediately see that it wasn't secure, the feeling was
that the chances of it being successfully challenged in court were negligible.
This is at least in part because of signed (on paper) agreements assigning
responsibility (there are local variations on this, e.g. in the military you
can be ordered to accept the ToS just as they can order you to walk through a
minefield).

Banks got by with simple checksums for some decades without any major legal
problems...

Peter.

From: "Santosh Chokhani" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>
Subject: RE: TSA certificate content
Date: Mon, 24 Nov 2003 21:40:56 -0500
Importance: Normal
Sender: [email-masked]

Peter:

Based on a review of 3280 and 3161, I would say that absence of keyUsage
extension is permissible.

3161 requires extended key usage to be present as well as critical.  It also
requires only one key purpose in the extension, that for time stamping.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Sylvester
Sent: Monday, November 24, 2003 8:30 AM
To: [email-masked]
Subject: TSA certificate content

I would like to hear some opinion about the setting
of the extension keyUsage in a certificate for a
3161 TSA. 

The question is whether a certificate contain no
keyUsage extension at all and only an extended
key usage with the appropriate key purpose
is conformant with 3161 and 3280. 

Peter 

Date: Fri, 28 Nov 2003 14:22:42 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Mike just gave me an offline whack to the head.

I have no objection to the original nonceUnsupported proposal, as 
described in
	http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
including David's "return an error" addition in
	http://www.imc.org/ietf-pkix/mail-archive/msg07214.html

Having clarified my earlier clarification, I wish to reset the 
conversation...

Florian: As we both support the proposal, we may be in danger of violent 
agreement.

Ryan: Your arguments have failed to convince me that the proposal is bad.

Apologies to all for the churn.

		M.

Michael Myers wrote:
> Marc,
> 
> The proposal is to cycle *v1* at Proposed to address this one
> issue.
> We would also take the opportunity to clarify encoding of nonce
> as OCTET STRING, which was going to happen anyway as v1 went
> from
> Proposed to Draft.
> 
> I take it then you have no objection to the core technical
> aspects of the proposed resolution?
> 
> Mike
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of
>>Marc Branchaud
>>Sent: Friday, November 28, 2003 10:28 AM
>>To: [email-masked]
>>Subject: Re: DISCUSS: MUST reject in OCSPv1
>>
>>
>>
>>Michael Myers wrote:
>>
>>>Marc, your response was ambiguous.
>>
>>Just to clarify, then:
>>
>>The resolution started with a "big if": Cycling at
>>proposed.  I have no
>>objection to cycling at Proposed and issuing an
>>OCSPv2 that works all
>>this out.
>>
>>It's the "then" I am objecting to.  The proposed
>>"then" is bad.
>>
>>		M.
>>
> 
> 

--------------ms010405000203000207060000
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

--------------ms010405000203000207060000--

From: "Ambarish Malpani" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "'Marc Branchaud'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 14:00:55 -0800
Importance: Normal
Sender: [email-masked]

Hi Florian,
    The reason for including a nonce in the request is to enable a
client that doesn't have a very precise knowledge of time to still
be sure the response he got from the server was generated for this
specific request.

While I do agree with Mark and think that the "right" way would be
to require the client to require the nonce in the response, in the
interests of moving ahead, I vote to accept Mike's compromise
proposal that a client MUST require the nonce in the response
unless it is accompanied by a nonceUnsupported extension in
the response and the client is willing to accept a response w/o
a nonce. This preserves the semantics for current clients and
still allows caching servers to supply responses to clients
who will take them.

Regards,
Ambarish

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
> Sent: Thursday, November 27, 2003 4:15 PM
> To: 'Marc Branchaud'; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Your argument is "nonces are only for replay protection". Thats true.
> 
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, the
> client is not harmed by a replay. So why should a client include a nonce
> into the request?
> 
> There are different reasons for that, but the main reason is: the client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
> 
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 20:56:41 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> > I agree. But the client behaves differently! It may
> > - display a warning to the user
> 
> Please.

Our client actually does in the default configuration. Sorry that I
(once again) could not live up to your imagination.

> > - apply another local policy regarding time checking
> > - add additional measures to ensure freshness if a nonce is not 
> > present
> > - etc.
> 
> Why not apply those measures in the first place and not 
> bother with the 
> nonce?

Come on. Answer that one for yourself. Those additional measures do not
come at no cost. E.g. contacting a trusted time source costs time. 

> Putting nonces into requests willy-nilly, just in case, is bad design.

Read the above. A response with nonce will trigger another handling than
a response without nonce according to the local policy. 

-- 
Florian Oelmaier
SyTrust

From: "Michael Myers" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 11:22:24 -0700
Importance: Normal
Sender: [email-masked]

Marc,

The proposal is to cycle *v1* at Proposed to address this one
issue.
We would also take the opportunity to clarify encoding of nonce
as OCTET STRING, which was going to happen anyway as v1 went
from
Proposed to Draft.

I take it then you have no objection to the core technical
aspects of the proposed resolution?

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Marc Branchaud
> Sent: Friday, November 28, 2003 10:28 AM
> To: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
> Michael Myers wrote:
> >
> > Marc, your response was ambiguous.
>
> Just to clarify, then:
>
> The resolution started with a "big if": Cycling at
> proposed.  I have no
> objection to cycling at Proposed and issuing an
> OCSPv2 that works all
> this out.
>
> It's the "then" I am objecting to.  The proposed
> "then" is bad.
>
> 		M.
>

Date: Fri, 28 Nov 2003 09:51:44 -0800
From: Marc Branchaud <[email-masked]>
To: David Engberg <[email-masked]>
CC: [email-masked]
Subject: Re: Digression:  nonces prevent replay?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Do nonces prevent replay attacks?
Yes, they do.

Do nonces "automatically confer absolute freshness and correctness"?
No, they prevent replay attacks.

Is there a ton of other problems and attacks that nonces don't solve?
Yes, there is.

Should OCSP try to leverage nonces to solve these other problems?
No, it shouldn't.

		M.

--------------ms040704070706060800040606
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

--------------ms040704070706060800040606--

Date: Fri, 28 Nov 2003 09:40:06 -0800
From: Marc Branchaud <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Ryan M. Hurst wrote:
> 
> [rmh] The question is does it want it or does it need it, in the case I 
> gave the bookstore.com server would be happy with any response thats not 
> expired; maybe the pre-production responder already has one that meets 
> that criteria.

If the client doesn't need it, then it shouldn't use it.  To do 
otherwise makes for a bad protocol.

		M.

--------------ms070106080409010800080000
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

--------------ms070106080409010800080000--

Date: Fri, 28 Nov 2003 09:33:17 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Florian Oelmaier wrote:
>>If the client puts a nonce in a request and doesn't behave differently 
>>depending on the presence/absence of the nonce in the response, then why 
>>put the nonce in at all?
> 
> I agree. But the client behaves differently! It may
> - display a warning to the user

Please.

> - apply another local policy regarding time checking
> - add additional measures to ensure freshness if a nonce is not present
> - etc.

Why not apply those measures in the first place and not bother with the 
nonce?

If the client has a policy that can let it live with the risk of replay 
within certain parameters, then it has no need for nonces.

Putting nonces into requests willy-nilly, just in case, is bad design.

		M.

--------------ms070200010103030102090402
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

--------------ms070200010103030102090402--

Date: Fri, 28 Nov 2003 09:27:44 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Michael Myers wrote:
> 
> Marc, your response was ambiguous.

Just to clarify, then:

The resolution started with a "big if": Cycling at proposed.  I have no 
objection to cycling at Proposed and issuing an OCSPv2 that works all 
this out.

It's the "then" I am objecting to.  The proposed "then" is bad.

		M.

--------------ms070809080805000405090205
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

--------------ms070809080805000405090205--

From: "Michael Myers" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, "Marc Branchaud" <[email-masked]>, <[email-masked]>
Subject: DIGRESS:   MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 09:47:27 -0700
Importance: Normal
Sender: [email-masked]

If we must digress, and I think it's useful to do so, let's do
it here.

Marc wrote:
> If the group wishes to address the use of nonces for more than
replay
> prevention, then I think the only option is to devise a new
OCSPv2
> spec.

Ryan wrote:
> [rmh] its not necesssary, the current RFC works and by
changing the
> semantics you disallow a legitimate use that worked and was
> conformant.

Marc countered:
> But that use wasn't conformant.  All that RFC2560 wants to use
nonces
> for is to prevent replay attacks.  Any other use of nonces
goes beyond
> what RFC2560 says they're for.

Ryan responded:
> [rmh] it absolutley is; find the text that precludes this
behavior.

To which I comment:

I dislike negative requirements.  They are untestable and are
therefore useless in customer acceptance testing.  Neither
should an OCSP server bake bread, but I didn't think it
necessary to point this out.

A potential improvement in degree of freshness is inherent in
the use of nonces.  This is, however, a secondary effect.  The
primary purpose of nonces is to address replay attacks:

"4.4.1  Nonce
The nonce cryptographically binds a request
and a response to prevent replay attacks."

Any secondary interpretation of nonce extension usage that
preserves this primary effect is arguably conformant.

Any secondary interpretation of nonce extension usage that does
not preserve this primary effect is by definition
non-conformant.

Mike

Date: Thu, 27 Nov 2003 04:36:04 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  
  [Snippage]

Peter.

Date: Wed, 26 Nov 2003 12:29:18 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Michael,

Do you believe any problems are solved by labeling of gasoline octane? 
The issuer of the gasoline advertises that it meets a certain technical 
specification, and each relying party decides what octane is required in 
his particular automobile.

With regard to granularity, some years ago there was a "Sunoco Custom 
Blending Pump" where you could dial up the exact quality of gasoline 
desired.  In my opinion, that's overkill - three grades is plenty. 
(Don't mention the different combinations of additives, which may vary 
by season, required by each of the 50 US states.  If any area cried out 
for policy standardization and granularity reduction, that is it.)

Three, coincidentally, is approximately the number of certificate 
policies actually used by the Department of Defense PKI.  Any number 
greater than two and less than six is a good number :-).

Dave

Michael Str�der wrote:

> Personally I'm not aware of any problems solved with the help of policy 
> OIDs. ;-) Maybe others on this list feel more enlightened.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 12:27:02 -0400
Sender: [email-masked]

Mike:

I do not know if this was said or not, but with the new extension, a 
compliant Responder must not be permitted to switch between nonce supported 
and nonce not supported responses

On Fri, 28 Nov 2003 08:05:56 -0700, Michael Myers wrote
> These are constructive discussions but somewhat off topic for
> this thread.  We need to determine if we as a WG can agree on a
> least-impact near term path forward for disambiguating the
> relationship between nonces and pre-produced responses.
> 
> After much work, we finally have a potential resolution on the
> table.
> 
> David and Florian agree with it.
> Ryan does not.
> Marc, your response was ambiguous.
> 
> Anyone else care to voice an opinion on the proposal?
> 
> Mike

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 14:05:32 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Cc: "Carlisle Adams" <[email-masked]>
Sender: [email-masked]

I know this isn't a poll, but to be clear MSFT does not support the MUST
reject in v1, nor the creation of a v2 for the nonce reason alone.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Wednesday, November 26, 2003 12:05 PM
To: [email-masked]
Cc: Carlisle Adams
Subject: DISCUSS: MUST reject in OCSPv1

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.

Mike

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 17:24:45 -0700
Importance: Normal
Sender: [email-masked]

Dave,

As I hope you realize, I take your point in a v2 context.
However, in v1, there was no discussion whatsoever regarding
conditional incorporation of a client's nonce.  This is a new
requirement, leading to new processing functionality and
doubtless must be taken up in v2 on that basis.

Meanwhile I remained disturbed that this WG of the IETF Security
Area will walk away from this issue tacitly condoning an
insecure practice by inaction on "MUST reject".  It's a tough
call, I know, but one that is supported by prior poll and an
issue that begs clarification before this insecure practice
finds it way to even more environments.  At least, that's my
opinion.

I should note as well that another of this WG's products, SCVP,
very clearly respects the underlying principle.  c.f. Section
3.4 of
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
where it is stated that:

    "If the client includes a requestNonce value
    in the request, then the server MUST return the
    same value in the response."

So again, it's not like this WG is blind the principle.

If "MUST reject" in v1 causes such pain, then find alternative
means to signal to the relying party that their use of nonces is
not acceptable and thus motivate a retry.  Goodness knows, web
surfers today receive ample notice that cookies must be enabled
to participate on many sites.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Wednesday, November 26, 2003 3:20 PM
> To: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> In brief:  I would object to a plan to require that
> v1-compatible
> clients MUST reject nonceless responses for nonced
> requests, regardless
> of local security policy.  I would favor a plan to
> strongly recommend
> that v1-compatible clients SHOULD reject nonceless
> responses for nonced
> requests.
>
> Rationale:
>
> Imagine an OCSP client who receives signed email with
> a cert from Acme
> Certs.  He chains it up (e.g through bridging) to
> some trusted root, and
> then finds Acme's responder URL through the cert's
> AIA field.  The
> client trusts the cert, but needs to validate its
> revocation status
> through OCSP.  With the "MUST" language, the client
> is limited to two
> automatically-enforced local security policies:
>
>    1) Don't send a nonce, whether or not Acme's
> server supports nonces.
>
>    2) Send a nonce whether or not Acme's server
> supports nonces, and
>       fail to perform any validation if it does not.
>
> These two local security policies are both perfectly
> valid for many
> users, but the indirect question being asked is:  Are
> these the ONLY two
> security policies that v1 OCSP clients may permit
> users to choose.
>
> I posit that there is a third local security policy
> that the MUST
> language prohibits, and that policy can be achieved
> under v1 SHOULD
> language:
>
>    3) Send a nonce to Acme's server, and accept the
> response IFF
>       the response contains the nonce OR the server
> SECURELY signals
>       that it does not supply nonces to anyone.
>
> There was plenty of discussion around the best way to
> achieve this
> secure signalling, but there was overwhelming
> consensus on this list
> that this should at least be a theoretical option.
> By using SHOULD, you
> permit willing clients and servers to extend RFC2560
> (that's what
> extensions are there for?) to adopt such an optional
> security model,
> rather than arbitrarily preventing all such extensibility.
>
> No one is arguing that this third local security
> policy must be
> implemented by every client and server, but by
> adopting language using
> SHOULD instead of MUST, you will permit v1-compliant
> servers and clients
> to at least consider implementing such a policy
> before v2-final in a few
> years.
>
>
>

Date: Wed, 26 Nov 2003 17:19:48 -0500
From: David Engberg <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

In brief:  I would object to a plan to require that v1-compatible 
clients MUST reject nonceless responses for nonced requests, regardless 
of local security policy.  I would favor a plan to strongly recommend 
that v1-compatible clients SHOULD reject nonceless responses for nonced 
requests.

Rationale:

Imagine an OCSP client who receives signed email with a cert from Acme 
Certs.  He chains it up (e.g through bridging) to some trusted root, and 
then finds Acme's responder URL through the cert's AIA field.  The 
client trusts the cert, but needs to validate its revocation status 
through OCSP.  With the "MUST" language, the client is limited to two 
automatically-enforced local security policies:

   1) Don't send a nonce, whether or not Acme's server supports nonces.

   2) Send a nonce whether or not Acme's server supports nonces, and
      fail to perform any validation if it does not.

These two local security policies are both perfectly valid for many 
users, but the indirect question being asked is:  Are these the ONLY two 
security policies that v1 OCSP clients may permit users to choose.

I posit that there is a third local security policy that the MUST 
language prohibits, and that policy can be achieved under v1 SHOULD 
language:

   3) Send a nonce to Acme's server, and accept the response IFF
      the response contains the nonce OR the server SECURELY signals
      that it does not supply nonces to anyone.

There was plenty of discussion around the best way to achieve this 
secure signalling, but there was overwhelming consensus on this list 
that this should at least be a theoretical option.  By using SHOULD, you 
permit willing clients and servers to extend RFC2560 (that's what 
extensions are there for?) to adopt such an optional security model, 
rather than arbitrarily preventing all such extensibility.

No one is arguing that this third local security policy must be 
implemented by every client and server, but by adopting language using 
SHOULD instead of MUST, you will permit v1-compliant servers and clients 
to at least consider implementing such a policy before v2-final in a few 
years.

Date: Thu, 27 Nov 2003 16:44:53 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Peter Gutmann wrote:
> consumer protection legislation,

I'm not a lawyer and the terms are for sure used much differently in other
countries. But I also guess that most ToS-style CPs would not withstand a
court trial based on german AGB-Gesetz, the law regulating "Allgemeine
Gesch�ftsbedingungen" (similar to ToS).

But since PKI did not hit the mass market yet a CA with such a ToS-style CP
can assume that this risk is quite low.
Less RPs => less serious usage => less risks. ;-)

Ciao, Michael.

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Straw poll: An advice to a commercial CA
Date: Thu, 27 Nov 2003 15:02:56 +0100
Sender: [email-masked]

>If cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"? 

Oh Peter, now you become far too practical for _this_ list!

But it is indeed a real challenge to write a GUI to be used by
ordinary IS administrators, for a mechanism that you need a Phd
or better to grasp!

I guess you can wait with the GUI as long as Microsoft will
wait with a GUI in their products.  That is, forever.

Eureka, I got it!  Since this is black magic anyway, Microsoft
could make this configurable with Regedit!  That's how MSFT
usually treat stuff that you really shouldn't muck around with
at all or only on your own risk.  Finally RFC3280 has found
its true sole-mate.  It was a long journey...

Anders

From: "Florian Oelmaier" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 00:38:13 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

Hello Marc,

> > I object. It breaks running code in installations.
> 
> That code is not secure, and did not follow the spec.

Accept it or not, but even code not using nonces is secure! At least as
secure as using CRLs. And definitely better than not checking revocation
at all.

If we follow the path of your arguments, we should make nonce a
requirement in OCSP. Seeing the TLS OCSP extensions this renders OCSP
unusable. If we agree that pre-produced responses are reasonable for
some use-cases, then you cannot argue that code accepting nonce-less
responses is not secure.

> > Seeing this it is a very acceptable for a client to TRY to get a 
> > nonce, but to accept answers without nonces as a fallback.
> 
> No, it is not acceptable.  The RFC is very clear: use nonces 
> to prevent 
> replay attacks.  If the client is concerned about replay attacks, it 
> must reject a nonceless response.

Most clients are concerned about replay attacks. But the first priority
of an OCSP-client is to get secure revocation information (at least the
same quality as a CRL). If the client is also able to get replay
protection, fine!

> > It is a "natural"
> > behaviour - I try for all extensions I support, but will 
> fall back to 
> > the very basics of the standard, to the "not extended" 
> behaviour when 
> > I cannot get what I want. This is the usual way of doing things in 
> > nearly all protocols out there, PKIX or not.
> 
> Nearly all protocols out there are insecure.  This is a security WG...

[A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
security are not mutually exclusive.

Date: Thu, 27 Nov 2003 15:53:12 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Florian Oelmaier wrote:
> 
>>>I object. It breaks running code in installations.
>>
>>That code is not secure, and did not follow the spec.
> 
> Accept it or not, but even code not using nonces is secure! At least as
> secure as using CRLs. And definitely better than not checking revocation
> at all.

Yes, it is just as secure as using CRLs.  CRLs are also vulnerable to 
replay attacks.  OCSP has a mechanism - nonces - to thwart replay 
attacks.  Code that abuses (or just doesn't use) that mechanism is 
insecure against replay attacks.

> If we follow the path of your arguments, we should make nonce a
> requirement in OCSP.

Not at all.  Many environments are perfectly fine with the risk of 
replay attacks.

> Seeing the TLS OCSP extensions this renders OCSP
> unusable.

I don't see how that follows.

> If we agree that pre-produced responses are reasonable for
> some use-cases, then you cannot argue that code accepting nonce-less
> responses is not secure.

That's not my argument.  The crux is whether a nonce is in the request.

If the request as a nonce, then the response MUST echo the nonce and the 
client MUST reject a nonceless response.  Why?  Because nonces are how 
OCSP prevents replay attacks.  To act any other way fails to prevent 
replay attacks.

However, if the request does _not_ have a nonce, then the client is 
perfectly free to accept nonceless (or nonceful) responses.

> Most clients are concerned about replay attacks.

Not the ones that don't care about nonces in responses.

> But the first priority
> of an OCSP-client is to get secure revocation information (at least the
> same quality as a CRL). If the client is also able to get replay
> protection, fine!

If the client puts a nonce in a request and doesn't behave differently 
depending on the presence/absence of the nonce in the response, then why 
put the nonce in at all?

>>Nearly all protocols out there are insecure.  This is a security WG...
> 
> [A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
> security are not mutually exclusive.

Nonces are not a feature-fallback mechanism.  Nonces prevent replay 
attacks.  If you want feature-fallback, you need to carefully consider 
the mechanism(s) you use.  Overloading the use of nonces as OCSPv1 
progresses up the standards track is wrong, ill-advised and insecure.

		M.

--------------ms020802090503030700060305
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

--------------ms020802090503030700060305--

Date: Thu, 27 Nov 2003 05:59:48 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

Peter.

Date: Thu, 27 Nov 2003 04:42:05 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter.

Date: 28 Nov 2003 09:00:09 -0000
From: "Florian Oelmaier" <[email-masked]>
To: Marc Branchaud <[email-masked]>, [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

> If the client puts a nonce in a request and doesn't behave differently 
> depending on the presence/absence of the nonce in the response, then why 
> put the nonce in at all?

I agree. But the client behaves differently! It may
- display a warning to the user
- apply another local policy regarding time checking
- add additional measures to ensure freshness if a nonce is not present
- etc.

-- 
Florian Oelmaier
SyTrust

Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

>the SPD entry ordering would have prevented this in a manner that no amount of

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve

From: "Hans Nilsson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 16:12:53 +0100
Sender: [email-masked]

I know of at least one CA product (SmartTrust Certificate Manager) which can
supports multiple issuance of certs (with different CPs) per CA root.

I know that this feature also is used by several of SmartTrust's customers,
for example for distinguishing between different issuing procedures and/or
private key storage media.

And when talking about Relying Party software, we do not usually mean
Outlook Express. After all, secure e-mail is not the number 1 PKI
application. 
Instead, RPs are usually servers, validating signatures in e-government and
e-banking applications. And RP software (from MS and others) can pick out
any field of a certificate and make a decision based on that.

Hans

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 2:30 PM
> To: [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> Hum,
> 
> I wonder how many times I have to repeat the same very basic
> questions and only getting answers back in "ASN.1"?  Sort of.
> So here we go again...
> 
> Because they have understood the problems associated?
> Because they enjoy "violating" standards?
> Because they are ignorant?
> Because their budget is too limited?
> Other?
> 
> Anders
> 
> ----- Original Message -----
> From: "Santosh Chokhani" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, November 26, 2003 12:04
> Subject: RE: Certificate Policy Standardization
> 
> 
> 
> Anders:
> 
> The relying parties are free to ignore the policies and policy related
> extensions altogether and verify paths.  The certification path will
verify
> unless:
> 
> 1.  One or more CAs in the path require that the certification path be
valid
> for a policy; or
> 
> 2.  Make the policy related extensions critical.
> 
> While some may view the two conditions as interoperability problem, I view
> it CA(s) saying that I do not want you to use the certificate unless you
> understand and abide by constraints I impose on the certificates.
> 
> The current X.509 and RFC 3280 permit you build PKI and applications that
do
> not use certificate policies.  So, I do not quite understand your concern
> below.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 4:03 AM
> To: Santosh Chokhani; [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> 
> 
> >I am not what you mean by ".....another useless PKIX bloat extension".
> 
> >If properly used by the CA and relying party systems, the certificate
> >policy OID can be used to provide amount of trust the relying party
> >should place in a certificate.
> 
> What Michael referred to as "bloat" is not policy identifiers themselves
but
> that they need another trust adminstration GUI and associated hassles.
> 
> Policy identifiers used for path validation purposes is indeed a very
> "fancy" thing from a technical point of view (maybe 2% of the people
> subscribed to the PKIX list can understand this part of RFC3280...), but
> from an interoperability point of view they are not that great.
> 
> Hum, there simply must be a reason why practically all commercial CAs have
> selected an entirely different approach.  And that they did this
completely
> on their own without any commitee descision etc.
> 
> I wonder how this really happend.   Could it be...
> 
>     that it sort of feels "natural"?
> 
> /a
> 

Date: Wed, 26 Nov 2003 10:06:41 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

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

At 14:30 +0100 11/26/03, Anders Rundgren wrote:
>Hum,
>
>I wonder how many times I have to repeat the same very basic
>questions and only getting answers back in "ASN.1"?  Sort of.
>So here we go again...
>

one might ask why the most widely distributed product that claims to 
implement IPsec  (Windows) does not provide a user/administrator the 
ability to order SPD entries, as required by RFC 2401. The answer is 
that the implementors did not understand why this was an important 
(in the case of IPsec, a critical) aspect of the standard and so the 
implementors omitted an important management control.

what one can learn from this an similar examples is that vendors are 
a very poor basis for determining the worth of a feature in a 
standard. a very big vendor can screw up an implementation and get 
away with it due to market dominance. other vendors, eager to be 
compatible with the dominant vendor, follow suit.  most users may not 
understand a complex technology and don't know what's missing.

>Because they have understood the problems associated?

sometimes, but rarely, in my experience.

>Because they enjoy "violating" standards?

"enjoy" is probably the wrong term, but "don't care" is accurate.

>Because they are ignorant?

sometimes, yes!

>Because their budget is too limited?

prioritization of development resources, combined with time to market 
pressure is often the reason that a vendor omits certain features.

>Other?

yes, you left out implementors who have decided that in the market 
niche of interest to them, they have a "better" way of implementing a 
capability that is incompatible with the standard and so they pursue 
their proprietary approach.

Steve
--============_-1142263285==_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 Policy
Standardization</title></head><body>
<div>At 14:30 +0100 11/26/03, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>Hum,<br>
<br>
I wonder how many times I have to repeat the same very basic<br>
questions and only getting answers back in &quot;ASN.1&quot;?&nbsp;
Sort of.<br>
So here we go again...<br>
<br>
1. Why does practically no shrink-wrap PKI-enabled software<br>
package support any kind of certificate policy settings?</blockquote>
<div><br></div>
<div>one might ask why the most widely distributed product that claims
to implement IPsec&nbsp; (Windows) does not provide a
user/administrator the ability to order SPD entries, as required by
RFC 2401. The answer is that the implementors did not understand why
this was an important (in the case of IPsec, a<u> critical</u>) aspect
of the standard and so the implementors omitted an important
management control.</div>
<div><br></div>
<div>what one can learn from this an similar examples is that vendors
are a very poor basis for determining the worth of a feature in a
standard. a very big vendor can screw up an implementation and get
away with it due to market dominance. other vendors, eager to be
compatible with the dominant vendor, follow suit.&nbsp; most users may
not understand a complex technology and don't know what's
missing.</div>
<div><br></div>
<blockquote type="cite" cite>2. And why do few if any commercial CAs
support multiple<br>
issuances (i.e. different CPs) per CA root?<br>
<br>
Because they have understood the problems associated?</blockquote>
<div><br>
sometimes, but rarely, in my experience.<br>
</div>
<blockquote type="cite" cite>Because they enjoy &quot;violating&quot;
standards?</blockquote>
<div><br></div>
<div>&quot;enjoy&quot; is probably the wrong term, but &quot;don't
care&quot; is accurate.</div>
<div><br></div>
<blockquote type="cite" cite>Because they are ignorant?</blockquote>
<div><br></div>
<div>sometimes, yes!</div>
<div><br></div>
<blockquote type="cite" cite>Because their budget is too
limited?</blockquote>
<div><br></div>
<div>prioritization of development resources, combined with time to
market pressure is often the reason that a vendor omits certain
features.</div>
<div><br></div>
<blockquote type="cite" cite>Other?</blockquote>
<div><br></div>
<div>yes, you left out implementors who have decided that in the
market niche of interest to them, they have a &quot;better&quot; way
of implementing a capability that is incompatible with the standard
and so they pursue their proprietary approach.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1142263285==_ma============--

Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 27 Nov 2003 04:13:30 +1300, [email-masked] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[email-masked]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Richard Levitte - VMS Whacker" <[email-masked]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:31:19 +0100
Sender: [email-masked]

>For me, OIDs are yet to have their time. As a concept they are elegant
>but will resist widespread use until security-exploiting applications
>support them. Until then they are destined to stay on the back-burner.

Sure.

>I encourage people to adopt their use, however, if only to future-proof
>themselves and I don't see any harm whatsoever in embedding in a certificate
>some mechanism that links the trust level it represents to a real-world
>legal mechanism, even if at present the software support for such a link
>is absent.

In case you are advicing people setting up CAs, I would (in case the
CP OID stuff stays forever in the backburner), also recommend them
to only apply one CP per CA root, as anyhting else is actually
incompatible with some 99.9% of existing RP software.

/anders

Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

>the SPD entry ordering would have prevented this in a manner that no amount of

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Chris

Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <025b01c3b421$683107b0$0500a8c0@arport> on Wed, 26 Nov 2003 14:30:06 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> I wonder how many times I have to repeat the same
anders.rundgren> very basic questions and only getting answers back in
anders.rundgren> "ASN.1"?  Sort of.  So here we go again...
anders.rundgren> 
anders.rundgren> 1. Why does practically no shrink-wrap PKI-enabled
anders.rundgren>    software package support any kind of certificate
anders.rundgren>    policy settings?
anders.rundgren> 
anders.rundgren> 2. And why do few if any commercial CAs support
anders.rundgren>    multiple issuances (i.e. different CPs) per CA
anders.rundgren>    root?
anders.rundgren> 
anders.rundgren> Because they have understood the problems associated?
anders.rundgren> Because they enjoy "violating" standards?
anders.rundgren> Because they are ignorant?
anders.rundgren> Because their budget is too limited?
anders.rundgren> Other?

Because they won't bother implementing something that a customer
hasn't asked for specifically.

I have literaly heard the sentence "Yeah, it would probably be useful
and might increase the value of our product, but no customer has said
they wanted or needed this, so we'll wait for that to happen".  And
this was for a product that had a lot to do with security.  It wasn't
about policy OIDs back then, but something similar enough.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Carlisle Adams" <[email-masked]>
Subject: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 13:04:42 -0700
Importance: Normal
Sender: [email-masked]

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.

Mike

Date: Thu, 27 Nov 2003 07:14:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  [...]

  [...]

  [...]

Peter.

From: "Anders Rundgren" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:52:10 +0100
Sender: [email-masked]

Richard,
That external parties to the US e-governments, like various
businesses would ever (on a wider scale) bother with cross-
certification is unlikely, they will just purchase a TTP-issued
"business certificate" for a few hundred dollars, not run CAs.

And in the case of the US e-government, they have a much more
serious problem to cater for than CP OIDs and that is that their
business parties, will authenticate messages at the business partner
level, not on employee level (as the latter is incompatible with
all e-business systems I have heard about).  So they probably
have to take down the whole thing and startover anyway.
Or have "gateway" servers do the transformation from their
internal "mess-PKI" (not mesh PKI) to something that works.
Like "flat", "boring", "simple",  you know.  In that world
CP OIDs are mostly unknown.   I have yet to find a CP OID
in my fairly new Thawte SSL certificate.

Anders

----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 26, 2003 14:30
Subject: Re: Certificate Policy Standardization

In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[email-masked]>
said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 26 Nov 2003 16:00:56 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <014b01c3b416$b6075580$0500a8c0@arport> on Wed, 26 Nov 2003 13:13:32 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> >I don't see how you can say that, Anders. That's not
anders.rundgren> >how the system is designed to work. No CA s/w that I
anders.rundgren> >have yet to encounter limits certificates to a
anders.rundgren> >single policy, let alone the CA. CertificatePolicies
anders.rundgren> >can be multivalued, is not a mandatory field, does
anders.rundgren> >not get marked as critical and in all except bespoke
anders.rundgren> >applications is currently ignored. Failure on the
anders.rundgren> >part of software developers to meet the agreed
anders.rundgren> >standards does not always indicate a failing of the
anders.rundgren> >standard (granted that in some cases it does).
anders.rundgren> 
anders.rundgren> Well Chris,
anders.rundgren> I think you read this in big haste.
anders.rundgren> 
anders.rundgren> CA s/w is not equivalent to RP s/w.
anders.rundgren> 
anders.rundgren> Please tell me where I in the latest edition of
anders.rundgren> Outlook Express (I'm indeed a daring guy...), can
anders.rundgren> "tweak" the CA policy trust settings.

That's today.  I believe that to the crowd, awareness of the type of
trust we're discussing here is fairly new (and in many cases so new
they aren't aware yet).  And M$ is fairly well-known for implementing
what it thinks the crowd wants and try to avoid things that could be
seen as complicated ("oh, I should protect my private key with a pass
phrase???"), so pardon me for rejecting that particular example.

I believe that when the crowd becomes a bit more aware of what their
actions mean when done through a computer, compared to the "real
world", they might demand  certain amount of control, and it's
perfectly possible that you will see those kinds of "knobs" sometime
in the future.

anders.rundgren> In case you don't find the "knob", does this in your
anders.rundgren> opinion mean that Microsoft is not
anders.rundgren> standards-compliant w.r.t. policy-OIDs?

Nope, it just means that they have assumed you would always press the
"Accept any policy" knob, and besides, that's all they currently
support, so the knob would be quite lonely in that otherwise empty
space, so they won't bother to put it up yet.

However, if M$ doesn't check for policy OID and mappings and keep
track of those along with the other data while verifying the path,
then they aren't standards-compliant w.r.t. policy OIDs.  As it is
right now, I wouldn't be surprised if they're in good company :-/.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 27 Nov 2003 04:13:30 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Peter.

Date: Thu, 27 Nov 2003 04:42:05 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter.

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Chris

Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

At 12:05 +0100 11/26/03, Anders Rundgren wrote:
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...

Date: Thu, 27 Nov 2003 04:36:04 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  
  [Snippage]

Peter.

Date: Thu, 27 Nov 2003 07:14:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  [...]

  [...]

  [...]

Peter.

Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

At 12:05 +0100 11/26/03, Anders Rundgren wrote:
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...

Date: Wed, 26 Nov 2003 11:59:18 -0500
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave

Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
> 

Date: Wed, 26 Nov 2003 09:19:55 -0500
From: jim <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Richard brings up an excellent point that should be considered by the 
members of this body.  On the horizon is the implementation of security 
middleware from a number of sources, which will allow for simpler 
PKEnablement of Web applications.  The issue in this regard is going to 
be the identification of how trust can be shared without having to go 
back to the original CA who issued a cert and cross-certifying CAs in 
that regard so that Internet commerce can be accomplished with many uses 
on the fly from disparate PKIs.  Meaningful OIDs offer a lot that can 
increase the success or failure of PK technology adaptation for 
commerce.  In that regard, please everyone, see what you can think of 
that will make this a useful and helpful solution to allow PK technology 
to flourish.

Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com

Richard Levitte - VMS Whacker wrote:

>In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[email-masked]> said:
>
>anders.rundgren> Policy OIDs may be "perfect" as long as you stay
>anders.rundgren> inside of your "walled garden", but the USs
>anders.rundgren> government PKI will likely find itself up the creek
>anders.rundgren> when they are going to connect to the outside world
>anders.rundgren> who hardly ever use this feature (which I BTW cannot
>anders.rundgren> find a single "knob" for in my W2K system), or even
>anders.rundgren> worse, have settled on another set of OIDs.
>
>Uhmm, especially that last thing about other PKIs having other sets
>of OIDs makes me think you have missed the mechanism called "policy
>mapping".  There's no requirement whatsoever that everyone uses the
>same set of OIDs.  However, if the owner of one PKI decides to do
>business with another PKI owner and have the two PKIs connected, they
>will typically do some cross certification, and those certificates
>will contain the appropriate mappings of policies, as decided by the
>two parties together.
>
>As far as I understand, those kinds of mechanisms are already in use
>and working.  I assume others here will be able to say yay or ney
>about this matter.
>
>Of course, what I said above implies some level of "meshness", about
>which I've read some negative comments from one person...
>
>-----
>Please consider sponsoring my work on free software.
>See http://www.free.lp.se/sponsoring.html for details.
>You don't have to be rich, a $10 donation is appreciated!
>
>  
>

Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <028101c3b424$7dd4b460$0500a8c0@arport> on Wed, 26 Nov 2003 14:52:10 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Richard,

Anders,

anders.rundgren> That external parties to the US e-governments, like
anders.rundgren> various businesses would ever (on a wider scale)
anders.rundgren> bother with cross-certification is unlikely, they
anders.rundgren> will just purchase a TTP-issued "business
anders.rundgren> certificate" for a few hundred dollars, not run CAs.

Wait, weren't you just asking about connecting different PKIs
together, or did I misunderstand you?  Going out shopping "business
certificates" will mean absolutely nothing in terms of PKI connection
unless everyone agrees to shop from the same CA.  I see that
happening, right...

It's true that smaller businesses will most likely not bother running
their own CA (unless they are run by techno-geeks like me, but that's
a different matter :-)).  I'm not so sure about larger ones...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 26 Nov 2003 09:49:16 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 19:07 +1300 11/26/03, Peter Gutmann wrote:
>>Note that with the advent of 3280, we decided to let protocols that are PKI
>>clients define extended key usage options for themselves.
>
>I recently had to deal with someone who's working with certs from (at least)
>two difference (largeish) public CAs.  One CA turned the eKU into a kind of
>lamp test packet, with every usage they could think of set ("Let's see, what
>have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
>and S/MIME, that sounds like a sensible combination of usages for a private
>key").  The other CA didn't populate the eKU at all, justifying it with
>"Everything ignores those anyway, so it doesn't matter what you put in there"
>(obviously they have to ignore them, in order to allow certs like the ones I'm
>describing to function).  In the end after taking legal considerations into
>account the conclusion was to define a new eKU, "doWhatISay", defined as "This
>key may only be used as we say it can be used" (it's not quite worded like
>that in their CPS, that'll take another six months for the lawyers to sort
>out).
>
>I dunno about the situation in the PKIX reality, but in the real world from
>the legal point of view (which is what matters in the end) that's about the
>best way to make use of eKU.
>
>Peter.

Your example is one in which CAs chose to make up their own, private 
EKUs. This is certainly allowed, but it is not what I said we had 
decided to do in the IETF, where we would expect EKU OIDs to be 
standardized by the cognizant WGs for the protocols with which the 
certs are used.

Also, you claim that what matters in the end is what "the legal point 
of view" says.  This is certainly true in some contexts, but not all 
certs are used in ways that have legal ramifications of the sort you 
imply. For example, most certs used with IKE will not be subject to 
some attorney's advice, I suspect.

Steve

Date: Fri, 28 Nov 2003 12:54:25 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>, Alice Sturgeon <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
Sender: [email-masked]

Alice and Russ,

I have sent several message about the status of  draft-ietf-pkix-warranty-extn.

My last message on that topic has been addressed to Alice, but I have not 
received a response yet.

Please, Russ, would you also clarify where we are now, with respect to the 
comments that I sent during the last call.

Denis

> Alice,
> 
> Does this new document addresses the issues I raised to the IESG during 
> the last call ?
> 
> If yes, would you please provide a resolution for my comments.
> 
> Denis
> 
> 
>> 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 Warranty 
>> Certificate Extension
>>     Author(s)    : D. Linsenbardt, S. Pontius, A. Sturgeon
>>     Filename    : draft-ietf-pkix-warranty-extn-04.txt
>>     Pages        : 8
>>     Date        : 2003-11-18
>>     
>> This document describes a certificate extension to explicitly state
>> the warranty offered by a Certificate Authority (CA) for a the
>> certificate containing the extension.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-04.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-warranty-extn-04.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-warranty-extn-04.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, 28 Nov 2003 08:33:20 -0500
To: Denis Pinkas <[email-masked]>, Alice Sturgeon <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
Cc: [email-masked]
Sender: [email-masked]

Denis:

Steve Bellovin is the shepherd for this document.  He will have more 
up-to-date information than me.

Russ

At 12:54 PM 11/28/2003 +0100, Denis Pinkas wrote:
>Please, Russ, would you also clarify where we are now, with respect to the 
>comments that I sent during the last call.

Date: Fri, 28 Nov 2003 14:16:42 +0100
To: "Peter Gutmann"<[email-masked] (Peter Gutmann)>
From: Christine Karman <[email-masked]>
Subject: Re: Straw poll: An advice to a commercial CA
Cc: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:27 11-27-03, Peter Gutmann wrote:

>To answer an earlier question about support for policy restrictions, cryptlib
>supports these (policy constraints with all its weird variations).  If
>cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"?

Typical users hardly know what a CA is. They don't know what kind of 
policies you are talking about. So a GUI would assume a most probable 
strategy, and then prompt the user with "I recommend you adopt policy xyz 
for this certificate. Press 'OK', or press 'advanced' to change". On a 
company level, a system administrator would force a certain behavior of the 
GUI, which cannot be changed by individual users.
Having said this, the GUI would probably make the choice by itself, because 
user interaction suggests that the user makes a decision on the subject, 
while in reality the user just presses a button that may as well read 
"Whatever".
I agree, this is not what the world should be like. But it is.

dagdag
Christine
--
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}--

Subject: 
To: [email-masked]
From: "Marco Nicoli" <[email-masked]>
Date: Fri, 28 Nov 2003 12:17:17 +0100
Sender: [email-masked]

remove

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 09:43:59 -0600
Importance: Normal
Sender: [email-masked]

I agree it is a good solution.

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 2:32 PM
> To: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> If anyone objects to the path forward as discussed below, please
> speak up now.  Concurrence is equally welcome.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > David Engberg
> > Sent: Thursday, November 27, 2003 12:46 PM
> > To: Michael Myers
> > Cc: [email-masked]
> > Subject: Re: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> >
> > Exactly.  I'd implement this right now if I wasn't so
> > full of turkey.
> >
> >
> > Michael Myers wrote:
> > >
> > > Understand your caching servers MUST send back a caveated
> > > response which by presence of the caveat may or may not be
> > > accepted.  No fair sending back plain ones, errors
> > > notwithstanding.  Is this understood?
> > >
> > > Mike
> > >
> > >
> > >>-----Original Message-----
> > >>From: David Engberg [mailto:[email-masked]]
> > >>Sent: Thursday, November 27, 2003 12:25 PM
> > >>To: Michael Myers
> > >>Cc: [email-masked]
> > >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> > >>
> > >>
> > >>
> > >>I'd add "or return an error [e.g. unauthorized?]" to
> > >>the end of '4' (to
> > >>remain compliant in the presence of requests for
> > >>unknown certs), but it
> > >>is otherwise my dream scenario.
> > >>
> > >>
> > >>Michael Myers wrote:
> > >>
> > >>>Dave,
> > >>>
> > >>>So how about:
> > >>>
> > >>>1. If we can cycle v1 at Proposed (a big if); then
> > >>>
> > >>>2. Define nonceUnsupported extension subject to
> > >>>   the following semantics (I'm squeezing the
> > >>>   words a bit but you'll get the drift)
> > >>>
> > >>>3. Clients that send a nonce:
> > >>>
> > >>>   a. MUST reject a non-nonced response
> > >>>      if that response includes either the
> > >>>      value "good" or "revoked" AND it fails
> > >>>      to include the nonceUnsupported extension;
> > >>>
> > >>>   b. Else, if such response includes the
> > >>>      nonceUnsupported extension, clients
> > >>>      MAY accept the response subject to the
> > >>>      advice in the Security Considerations
> > >>>      section of this document.
> > >>>
> > >>>4. Conversely, if a server receives a nonced
> > >>>   request but is unable to incorporate the
> > >>>   nonce in its response, the server MUST
> > >>>   include the nonceUnsupported extension.
> > >>>
> > >>> Note that I made no distinction between "good",
> > >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> > >>> a plain nonceless response of "good" or
> > >>> "revoked" is non-conformant, while a caveated
> > >>> response is subject to the client's local
> > >>> security policy.
> > >>>
> > >>> Does this seem a fair compromise?  Note well it's highly
> > >>> dependent on cycling v1 at Proposed.
> > >>>
> > >>> Mike
> > >
> > >
> > >
> >

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 08:05:56 -0700
Importance: Normal
Sender: [email-masked]

These are constructive discussions but somewhat off topic for
this thread.  We need to determine if we as a WG can agree on a
least-impact near term path forward for disambiguating the
relationship between nonces and pre-produced responses.

After much work, we finally have a potential resolution on the
table.

David and Florian agree with it.
Ryan does not.
Marc, your response was ambiguous.

Anyone else care to voice an opinion on the proposal?

Mike

Date: Fri, 28 Nov 2003 08:33:20 -0500
To: Denis Pinkas <[email-masked]>, Alice Sturgeon <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
Cc: [email-masked]
Sender: [email-masked]

Denis:

Steve Bellovin is the shepherd for this document.  He will have more 
up-to-date information than me.

Russ

At 12:54 PM 11/28/2003 +0100, Denis Pinkas wrote:
>Please, Russ, would you also clarify where we are now, with respect to the 
>comments that I sent during the last call.

Date: Fri, 28 Nov 2003 14:16:42 +0100
To: "Peter Gutmann"<[email-masked] (Peter Gutmann)>
From: Christine Karman <[email-masked]>
Subject: Re: Straw poll: An advice to a commercial CA
Cc: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:27 11-27-03, Peter Gutmann wrote:

>To answer an earlier question about support for policy restrictions, cryptlib
>supports these (policy constraints with all its weird variations).  If
>cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"?

Typical users hardly know what a CA is. They don't know what kind of 
policies you are talking about. So a GUI would assume a most probable 
strategy, and then prompt the user with "I recommend you adopt policy xyz 
for this certificate. Press 'OK', or press 'advanced' to change". On a 
company level, a system administrator would force a certain behavior of the 
GUI, which cannot be changed by individual users.
Having said this, the GUI would probably make the choice by itself, because 
user interaction suggests that the user makes a decision on the subject, 
while in reality the user just presses a button that may as well read 
"Whatever".
I agree, this is not what the world should be like. But it is.

dagdag
Christine
--
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}--

Date: Fri, 28 Nov 2003 12:54:25 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>, Alice Sturgeon <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
Sender: [email-masked]

Alice and Russ,

I have sent several message about the status of  draft-ietf-pkix-warranty-extn.

My last message on that topic has been addressed to Alice, but I have not 
received a response yet.

Please, Russ, would you also clarify where we are now, with respect to the 
comments that I sent during the last call.

Denis

> Alice,
> 
> Does this new document addresses the issues I raised to the IESG during 
> the last call ?
> 
> If yes, would you please provide a resolution for my comments.
> 
> Denis
> 
> 
>> 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 Warranty 
>> Certificate Extension
>>     Author(s)    : D. Linsenbardt, S. Pontius, A. Sturgeon
>>     Filename    : draft-ietf-pkix-warranty-extn-04.txt
>>     Pages        : 8
>>     Date        : 2003-11-18
>>     
>> This document describes a certificate extension to explicitly state
>> the warranty offered by a Certificate Authority (CA) for a the
>> certificate containing the extension.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-04.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-warranty-extn-04.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-warranty-extn-04.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.
> 
> 
> 

Subject: 
To: [email-masked]
From: "Marco Nicoli" <[email-masked]>
Date: Fri, 28 Nov 2003 12:17:17 +0100
Sender: [email-masked]

remove

Date: Thu, 27 Nov 2003 04:13:30 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Peter.

Date: Wed, 26 Nov 2003 09:19:55 -0500
From: jim <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Richard brings up an excellent point that should be considered by the 
members of this body.  On the horizon is the implementation of security 
middleware from a number of sources, which will allow for simpler 
PKEnablement of Web applications.  The issue in this regard is going to 
be the identification of how trust can be shared without having to go 
back to the original CA who issued a cert and cross-certifying CAs in 
that regard so that Internet commerce can be accomplished with many uses 
on the fly from disparate PKIs.  Meaningful OIDs offer a lot that can 
increase the success or failure of PK technology adaptation for 
commerce.  In that regard, please everyone, see what you can think of 
that will make this a useful and helpful solution to allow PK technology 
to flourish.

Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com

Richard Levitte - VMS Whacker wrote:

>In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[email-masked]> said:
>
>anders.rundgren> Policy OIDs may be "perfect" as long as you stay
>anders.rundgren> inside of your "walled garden", but the USs
>anders.rundgren> government PKI will likely find itself up the creek
>anders.rundgren> when they are going to connect to the outside world
>anders.rundgren> who hardly ever use this feature (which I BTW cannot
>anders.rundgren> find a single "knob" for in my W2K system), or even
>anders.rundgren> worse, have settled on another set of OIDs.
>
>Uhmm, especially that last thing about other PKIs having other sets
>of OIDs makes me think you have missed the mechanism called "policy
>mapping".  There's no requirement whatsoever that everyone uses the
>same set of OIDs.  However, if the owner of one PKI decides to do
>business with another PKI owner and have the two PKIs connected, they
>will typically do some cross certification, and those certificates
>will contain the appropriate mappings of policies, as decided by the
>two parties together.
>
>As far as I understand, those kinds of mechanisms are already in use
>and working.  I assume others here will be able to say yay or ney
>about this matter.
>
>Of course, what I said above implies some level of "meshness", about
>which I've read some negative comments from one person...
>
>-----
>Please consider sponsoring my work on free software.
>See http://www.free.lp.se/sponsoring.html for details.
>You don't have to be rich, a $10 donation is appreciated!
>
>  
>

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Richard Levitte - VMS Whacker" <[email-masked]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:31:19 +0100
Sender: [email-masked]

>For me, OIDs are yet to have their time. As a concept they are elegant
>but will resist widespread use until security-exploiting applications
>support them. Until then they are destined to stay on the back-burner.

Sure.

>I encourage people to adopt their use, however, if only to future-proof
>themselves and I don't see any harm whatsoever in embedding in a certificate
>some mechanism that links the trust level it represents to a real-world
>legal mechanism, even if at present the software support for such a link
>is absent.

In case you are advicing people setting up CAs, I would (in case the
CP OID stuff stays forever in the backburner), also recommend them
to only apply one CP per CA root, as anyhting else is actually
incompatible with some 99.9% of existing RP software.

/anders

From: "Anders Rundgren" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:52:10 +0100
Sender: [email-masked]

Richard,
That external parties to the US e-governments, like various
businesses would ever (on a wider scale) bother with cross-
certification is unlikely, they will just purchase a TTP-issued
"business certificate" for a few hundred dollars, not run CAs.

And in the case of the US e-government, they have a much more
serious problem to cater for than CP OIDs and that is that their
business parties, will authenticate messages at the business partner
level, not on employee level (as the latter is incompatible with
all e-business systems I have heard about).  So they probably
have to take down the whole thing and startover anyway.
Or have "gateway" servers do the transformation from their
internal "mess-PKI" (not mesh PKI) to something that works.
Like "flat", "boring", "simple",  you know.  In that world
CP OIDs are mostly unknown.   I have yet to find a CP OID
in my fairly new Thawte SSL certificate.

Anders

----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 26, 2003 14:30
Subject: Re: Certificate Policy Standardization

In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[email-masked]>
said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 27 Nov 2003 04:42:05 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter.

Date: Wed, 26 Nov 2003 16:00:56 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <014b01c3b416$b6075580$0500a8c0@arport> on Wed, 26 Nov 2003 13:13:32 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> >I don't see how you can say that, Anders. That's not
anders.rundgren> >how the system is designed to work. No CA s/w that I
anders.rundgren> >have yet to encounter limits certificates to a
anders.rundgren> >single policy, let alone the CA. CertificatePolicies
anders.rundgren> >can be multivalued, is not a mandatory field, does
anders.rundgren> >not get marked as critical and in all except bespoke
anders.rundgren> >applications is currently ignored. Failure on the
anders.rundgren> >part of software developers to meet the agreed
anders.rundgren> >standards does not always indicate a failing of the
anders.rundgren> >standard (granted that in some cases it does).
anders.rundgren> 
anders.rundgren> Well Chris,
anders.rundgren> I think you read this in big haste.
anders.rundgren> 
anders.rundgren> CA s/w is not equivalent to RP s/w.
anders.rundgren> 
anders.rundgren> Please tell me where I in the latest edition of
anders.rundgren> Outlook Express (I'm indeed a daring guy...), can
anders.rundgren> "tweak" the CA policy trust settings.

That's today.  I believe that to the crowd, awareness of the type of
trust we're discussing here is fairly new (and in many cases so new
they aren't aware yet).  And M$ is fairly well-known for implementing
what it thinks the crowd wants and try to avoid things that could be
seen as complicated ("oh, I should protect my private key with a pass
phrase???"), so pardon me for rejecting that particular example.

I believe that when the crowd becomes a bit more aware of what their
actions mean when done through a computer, compared to the "real
world", they might demand  certain amount of control, and it's
perfectly possible that you will see those kinds of "knobs" sometime
in the future.

anders.rundgren> In case you don't find the "knob", does this in your
anders.rundgren> opinion mean that Microsoft is not
anders.rundgren> standards-compliant w.r.t. policy-OIDs?

Nope, it just means that they have assumed you would always press the
"Accept any policy" knob, and besides, that's all they currently
support, so the knob would be quite lonely in that otherwise empty
space, so they won't bother to put it up yet.

However, if M$ doesn't check for policy OID and mappings and keep
track of those along with the other data while verifying the path,
then they aren't standards-compliant w.r.t. policy OIDs.  As it is
right now, I wouldn't be surprised if they're in good company :-/.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 26 Nov 2003 09:49:16 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 19:07 +1300 11/26/03, Peter Gutmann wrote:
>>Note that with the advent of 3280, we decided to let protocols that are PKI
>>clients define extended key usage options for themselves.
>
>I recently had to deal with someone who's working with certs from (at least)
>two difference (largeish) public CAs.  One CA turned the eKU into a kind of
>lamp test packet, with every usage they could think of set ("Let's see, what
>have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
>and S/MIME, that sounds like a sensible combination of usages for a private
>key").  The other CA didn't populate the eKU at all, justifying it with
>"Everything ignores those anyway, so it doesn't matter what you put in there"
>(obviously they have to ignore them, in order to allow certs like the ones I'm
>describing to function).  In the end after taking legal considerations into
>account the conclusion was to define a new eKU, "doWhatISay", defined as "This
>key may only be used as we say it can be used" (it's not quite worded like
>that in their CPS, that'll take another six months for the lawyers to sort
>out).
>
>I dunno about the situation in the PKIX reality, but in the real world from
>the legal point of view (which is what matters in the end) that's about the
>best way to make use of eKU.
>
>Peter.

Your example is one in which CAs chose to make up their own, private 
EKUs. This is certainly allowed, but it is not what I said we had 
decided to do in the IETF, where we would expect EKU OIDs to be 
standardized by the cognizant WGs for the protocols with which the 
certs are used.

Also, you claim that what matters in the end is what "the legal point 
of view" says.  This is certainly true in some contexts, but not all 
certs are used in ways that have legal ramifications of the sort you 
imply. For example, most certs used with IKE will not be subject to 
some attorney's advice, I suspect.

Steve

From: "Hans Nilsson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 16:12:53 +0100
Sender: [email-masked]

I know of at least one CA product (SmartTrust Certificate Manager) which can
supports multiple issuance of certs (with different CPs) per CA root.

I know that this feature also is used by several of SmartTrust's customers,
for example for distinguishing between different issuing procedures and/or
private key storage media.

And when talking about Relying Party software, we do not usually mean
Outlook Express. After all, secure e-mail is not the number 1 PKI
application. 
Instead, RPs are usually servers, validating signatures in e-government and
e-banking applications. And RP software (from MS and others) can pick out
any field of a certificate and make a decision based on that.

Hans

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 2:30 PM
> To: [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> Hum,
> 
> I wonder how many times I have to repeat the same very basic
> questions and only getting answers back in "ASN.1"?  Sort of.
> So here we go again...
> 
> Because they have understood the problems associated?
> Because they enjoy "violating" standards?
> Because they are ignorant?
> Because their budget is too limited?
> Other?
> 
> Anders
> 
> ----- Original Message -----
> From: "Santosh Chokhani" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, November 26, 2003 12:04
> Subject: RE: Certificate Policy Standardization
> 
> 
> 
> Anders:
> 
> The relying parties are free to ignore the policies and policy related
> extensions altogether and verify paths.  The certification path will
verify
> unless:
> 
> 1.  One or more CAs in the path require that the certification path be
valid
> for a policy; or
> 
> 2.  Make the policy related extensions critical.
> 
> While some may view the two conditions as interoperability problem, I view
> it CA(s) saying that I do not want you to use the certificate unless you
> understand and abide by constraints I impose on the certificates.
> 
> The current X.509 and RFC 3280 permit you build PKI and applications that
do
> not use certificate policies.  So, I do not quite understand your concern
> below.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 4:03 AM
> To: Santosh Chokhani; [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> 
> 
> >I am not what you mean by ".....another useless PKIX bloat extension".
> 
> >If properly used by the CA and relying party systems, the certificate
> >policy OID can be used to provide amount of trust the relying party
> >should place in a certificate.
> 
> What Michael referred to as "bloat" is not policy identifiers themselves
but
> that they need another trust adminstration GUI and associated hassles.
> 
> Policy identifiers used for path validation purposes is indeed a very
> "fancy" thing from a technical point of view (maybe 2% of the people
> subscribed to the PKIX list can understand this part of RFC3280...), but
> from an interoperability point of view they are not that great.
> 
> Hum, there simply must be a reason why practically all commercial CAs have
> selected an entirely different approach.  And that they did this
completely
> on their own without any commitee descision etc.
> 
> I wonder how this really happend.   Could it be...
> 
>     that it sort of feels "natural"?
> 
> /a
> 

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Chris

Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

At 12:05 +0100 11/26/03, Anders Rundgren wrote:
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Carlisle Adams" <[email-masked]>
Subject: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 13:04:42 -0700
Importance: Normal
Sender: [email-masked]

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.

Mike

Date: Thu, 27 Nov 2003 04:36:04 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  
  [Snippage]

Peter.

Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

At 12:05 +0100 11/26/03, Anders Rundgren wrote:
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...

Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

>the SPD entry ordering would have prevented this in a manner that no amount of

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve

Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <025b01c3b421$683107b0$0500a8c0@arport> on Wed, 26 Nov 2003 14:30:06 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> I wonder how many times I have to repeat the same
anders.rundgren> very basic questions and only getting answers back in
anders.rundgren> "ASN.1"?  Sort of.  So here we go again...
anders.rundgren> 
anders.rundgren> 1. Why does practically no shrink-wrap PKI-enabled
anders.rundgren>    software package support any kind of certificate
anders.rundgren>    policy settings?
anders.rundgren> 
anders.rundgren> 2. And why do few if any commercial CAs support
anders.rundgren>    multiple issuances (i.e. different CPs) per CA
anders.rundgren>    root?
anders.rundgren> 
anders.rundgren> Because they have understood the problems associated?
anders.rundgren> Because they enjoy "violating" standards?
anders.rundgren> Because they are ignorant?
anders.rundgren> Because their budget is too limited?
anders.rundgren> Other?

Because they won't bother implementing something that a customer
hasn't asked for specifically.

I have literaly heard the sentence "Yeah, it would probably be useful
and might increase the value of our product, but no customer has said
they wanted or needed this, so we'll wait for that to happen".  And
this was for a product that had a lot to do with security.  It wasn't
about policy OIDs back then, but something similar enough.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

>the SPD entry ordering would have prevented this in a manner that no amount of

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve

Date: Wed, 26 Nov 2003 10:06:41 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

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

At 14:30 +0100 11/26/03, Anders Rundgren wrote:
>Hum,
>
>I wonder how many times I have to repeat the same very basic
>questions and only getting answers back in "ASN.1"?  Sort of.
>So here we go again...
>

one might ask why the most widely distributed product that claims to 
implement IPsec  (Windows) does not provide a user/administrator the 
ability to order SPD entries, as required by RFC 2401. The answer is 
that the implementors did not understand why this was an important 
(in the case of IPsec, a critical) aspect of the standard and so the 
implementors omitted an important management control.

what one can learn from this an similar examples is that vendors are 
a very poor basis for determining the worth of a feature in a 
standard. a very big vendor can screw up an implementation and get 
away with it due to market dominance. other vendors, eager to be 
compatible with the dominant vendor, follow suit.  most users may not 
understand a complex technology and don't know what's missing.

>Because they have understood the problems associated?

sometimes, but rarely, in my experience.

>Because they enjoy "violating" standards?

"enjoy" is probably the wrong term, but "don't care" is accurate.

>Because they are ignorant?

sometimes, yes!

>Because their budget is too limited?

prioritization of development resources, combined with time to market 
pressure is often the reason that a vendor omits certain features.

>Other?

yes, you left out implementors who have decided that in the market 
niche of interest to them, they have a "better" way of implementing a 
capability that is incompatible with the standard and so they pursue 
their proprietary approach.

Steve
--============_-1142263285==_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 Policy
Standardization</title></head><body>
<div>At 14:30 +0100 11/26/03, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>Hum,<br>
<br>
I wonder how many times I have to repeat the same very basic<br>
questions and only getting answers back in &quot;ASN.1&quot;?&nbsp;
Sort of.<br>
So here we go again...<br>
<br>
1. Why does practically no shrink-wrap PKI-enabled software<br>
package support any kind of certificate policy settings?</blockquote>
<div><br></div>
<div>one might ask why the most widely distributed product that claims
to implement IPsec&nbsp; (Windows) does not provide a
user/administrator the ability to order SPD entries, as required by
RFC 2401. The answer is that the implementors did not understand why
this was an important (in the case of IPsec, a<u> critical</u>) aspect
of the standard and so the implementors omitted an important
management control.</div>
<div><br></div>
<div>what one can learn from this an similar examples is that vendors
are a very poor basis for determining the worth of a feature in a
standard. a very big vendor can screw up an implementation and get
away with it due to market dominance. other vendors, eager to be
compatible with the dominant vendor, follow suit.&nbsp; most users may
not understand a complex technology and don't know what's
missing.</div>
<div><br></div>
<blockquote type="cite" cite>2. And why do few if any commercial CAs
support multiple<br>
issuances (i.e. different CPs) per CA root?<br>
<br>
Because they have understood the problems associated?</blockquote>
<div><br>
sometimes, but rarely, in my experience.<br>
</div>
<blockquote type="cite" cite>Because they enjoy &quot;violating&quot;
standards?</blockquote>
<div><br></div>
<div>&quot;enjoy&quot; is probably the wrong term, but &quot;don't
care&quot; is accurate.</div>
<div><br></div>
<blockquote type="cite" cite>Because they are ignorant?</blockquote>
<div><br></div>
<div>sometimes, yes!</div>
<div><br></div>
<blockquote type="cite" cite>Because their budget is too
limited?</blockquote>
<div><br></div>
<div>prioritization of development resources, combined with time to
market pressure is often the reason that a vendor omits certain
features.</div>
<div><br></div>
<blockquote type="cite" cite>Other?</blockquote>
<div><br></div>
<div>yes, you left out implementors who have decided that in the
market niche of interest to them, they have a &quot;better&quot; way
of implementing a capability that is incompatible with the standard
and so they pursue their proprietary approach.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1142263285==_ma============--

Date: Thu, 27 Nov 2003 07:14:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  [...]

  [...]

  [...]

Peter.

Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 27 Nov 2003 04:13:30 +1300, [email-masked] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[email-masked]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Chris

Date: Thu, 27 Nov 2003 05:59:48 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

Peter.

Date: Wed, 26 Nov 2003 11:59:18 -0500
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave

Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
> 

Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <028101c3b424$7dd4b460$0500a8c0@arport> on Wed, 26 Nov 2003 14:52:10 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Richard,

Anders,

anders.rundgren> That external parties to the US e-governments, like
anders.rundgren> various businesses would ever (on a wider scale)
anders.rundgren> bother with cross-certification is unlikely, they
anders.rundgren> will just purchase a TTP-issued "business
anders.rundgren> certificate" for a few hundred dollars, not run CAs.

Wait, weren't you just asking about connecting different PKIs
together, or did I misunderstand you?  Going out shopping "business
certificates" will mean absolutely nothing in terms of PKI connection
unless everyone agrees to shop from the same CA.  I see that
happening, right...

It's true that smaller businesses will most likely not bother running
their own CA (unless they are run by techno-geeks like me, but that's
a different matter :-)).  I'm not so sure about larger ones...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 27 Nov 2003 07:14:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  [...]

  [...]

  [...]

Peter.

Date: Thu, 27 Nov 2003 04:42:05 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter.

Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 27 Nov 2003 04:13:30 +1300, [email-masked] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[email-masked]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: 28 Nov 2003 09:00:09 -0000
From: "Florian Oelmaier" <[email-masked]>
To: Marc Branchaud <[email-masked]>, [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

> If the client puts a nonce in a request and doesn't behave differently 
> depending on the presence/absence of the nonce in the response, then why 
> put the nonce in at all?

I agree. But the client behaves differently! It may
- display a warning to the user
- apply another local policy regarding time checking
- add additional measures to ensure freshness if a nonce is not present
- etc.

-- 
Florian Oelmaier
SyTrust

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Conclusion: Certificate Policy Standardization
Date: Fri, 28 Nov 2003 09:13:56 +0100
Sender: [email-masked]

Thank you folks for giving valuable input on this subject!

After compiling the numerous postings I believe that a number
of things are pretty clear:

1. Standardization of policy identifiers is unlikely to ever happen
    to the extent that policy OIDs can be pre-set in COTS SW [1].

2. The use of policy OIDs in path validation is for the same reason,
   as well as due to the lack of CP OID configuration support [2]
   in COTS SW, limited to "in-house" or "enterprise" type of trust-
   networks, where there are IS-departments that deal with
   "tweaking",  the usually custom RP software, for alignment with
   the trust-network-specific rules.

3. TTP CAs (who essentially compete with "in-house" type of CAs
   of the kind mentioned in #2), have no reason to abandon their
   issuance structure beyond the current CA <=> Policy level [3],
   as they have nothing to gain by doing that, except for numerous 
   commercial, technical, security, and legal problems.  

   Some readers claim that this is holding back "progress", but they
   apparently do not fully grasp the huge difference between running
   something like VeriSign's Web-server CA and an enterprise PKI.
   The short explanation is that the former is "unilateral",  and hardly
   ever engage in cross-certification etc.  To force Mc Donald's into
   recommending "Whoppers" is not going to happen.  For a reason.

Anders Rundgren

1] COTS SW.  Common Off-The Shelf SoftWare.

2] As indicated by Peter Guttman, configuration of CP OIDs is
   by no means ready for wide-scale deployment as many questions
   are still to be answered.  Due to the fact the the IETF is not working
   on this issue, we will essentially have to wait to see what Microsoft
   and other vendors believe is the "right way" to handle this.

3] This scheme also opens completely of new possibilities, like
   using the CA as a holder of meta-data, potentially simplifying
   RP trust administration, as a CA certificate can "describe" the
   issuance before a single EE-certificate has been received.

Date: Thu, 27 Nov 2003 23:53:30 -0500
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: [email-masked]
Subject: Digression:  nonces prevent replay?
Sender: [email-masked]

Marc Branchaud wrote:

> Yes, it is just as secure as using CRLs.  CRLs are also vulnerable to 
> replay attacks.  OCSP has a mechanism - nonces - to thwart replay 
> attacks.

The nonce mechanism "thwarts" or "prevents" replay attacks only in the 
most narrowly literal sense.

Imagine that I have a non-trivial PKI with a CA that publishes a 24-hour 
CRL every 6 hours into an LDAP directory.  Each CRL is then retrieved by 
a pair of geographically separate OCSP responders.

A client using nonces protected against the following attack:

   1) An attacker knows her cert will be revoked during one day.

   2) The attacker records a 'valid' OCSP response for her certificate
      at the beginning of the day.

   3) The attacker's cert is revoked and put on a CRL within a few hours.

   4) The attacker performs a signature for a relying party using
      her revoked cert, before the end of that day.

   5) The attacker fully controls networking between that relying
      party and the responder(s), but controls neither the RP or the
      responder.

   6) The relying party makes a request about that cert, the attacker
      intercepts and replays the stored "valid" response.

Basically, the nonce mechanism protects against a short term 
revocation-delaying attack that requires complete takeover of one link 
in the chain:  the network from the relying party to the responder.

(I've tried to come up with a real scenario where it would make sense 
for an attacker to choose this attack and carry it out for some kind of 
gain.  I keep coming up with Homer Simpson's response to a villain's 
plan:  "Of course! It's so simple! No, wait, it's needlessly complicated!")

What about attacks on the other links in the chain?

* CA Denial of Service:  prevent publication of new CRL, revocation is 
delayed (same end result as replay)

* CA -> LDAP network:  prevent distribution of new CRL, delay revocation 
(as replay)

* LDAP DoS:  prevent distribution of new CRL, delay revocation (as replay)

* LDAP -> responder network:  prevent distribution of new CRL, delay 
revocation (as replay)

* Responder intrusion/compromise:  use key to replay old response with 
new nonce (replay), or use key to create responses saying absolutely 
anything you want (reactivate stolen ID card, revoke your boss, etc.). 
No, an HSM doesn't prevent these.

* Reponder DoS:  prevent publication of revocation info, may get by as 
"unknown."  (Guard: "The servers are down again. Well, your badge looks 
good and I saw you this morning ... go ahead.")

* Relying Party intrusion/compromise:  ignore revocation (as replay)

My point is that a nonce only prevents one type of revocation-delaying 
attack.  This needs to be taken in the context of a full security 
analysis of your overall revocation infrastructure rather than assuming 
that nonces automatically confer absolute freshness and correctness.

Nonces may strengthen one link in a long chain, but they achieve this by 
significantly reducing the strength of another link (the responder). 
Nonces require online signing keys on public servers that accept 
thousands of HTTP requests per minute over public networks.  The impact 
of an intrusion/compromise of a key-bearing server is orders of 
magnitude more severe than any revocation delay caused by a replay attack.

We PKI folks may sometimes feel that real-world server security isn't 
our problem as long as the algorithms and protocols are pristine.  Until 
every app and OS is bug-free (and every employee with physical access to 
servers is perfect), we need to account for risks from boring old 
non-PKI server attacks like:

   http://www.cert.org/advisories/CA-2002-29.html

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 18:04:13 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B554.1EC1C1FC"

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

=20
cil

________________________________

From: [email-masked] on behalf of Marc Branchaud
Sent: Thu 11/27/2003 4:23 PM
To: [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1

That's all fine.  Really!

But why would the client not care if the nonce is echoed in the =
response?

The client should only ask for a fresh response if it really wants one.
To make frivolous requests for freshness would unnecessarily tax a
server that actually cares and tries to fulfill the requests.

[rmh] The question is does it want it or does it need it, in the case I =
gave the bookstore.com server would be happy with any response thats not =
expired; maybe the pre-production responder already has one that meets =
that criteria.

In the end, making the requirement anything less that "MUST reject" will
lead to servers simply ignoring the nonce extension altogether.

                M.

Florian Oelmaier wrote:
> Your argument is "nonces are only for replay protection". Thats true.
>
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, =
the
> client is not harmed by a replay. So why should a client include a =
nonce
> into the request?
>
> There are different reasons for that, but the main reason is: the =
client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
>
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
>

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>Re: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText2936 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr>cil<BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Thu 11/27/2003 4:23 PM<BR><B>To:</B> =0A=
[email-masked]<BR><B>Subject:</B> Re: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>That's all fine.&nbsp; Really!<BR><BR>But why would =
the client =0A=
not care if the nonce is echoed in the response?<BR><BR>The client =
should only =0A=
ask for a fresh response if it really wants one.<BR>To make frivolous =
requests =0A=
for freshness would unnecessarily tax a<BR>server that actually cares =
and tries =0A=
to fulfill the requests.</FONT></P>=0A=
<P><FONT size=3D2>[rmh] The question is does it want it or does it need =
it, in the =0A=
case I gave the bookstore.com server would be happy with any response =
thats not =0A=
expired; maybe the pre-production responder already has one that meets =
that =0A=
criteria.<BR><BR>In the end, making the requirement anything less that =
"MUST =0A=
reject" will<BR>lead to servers simply ignoring the nonce extension =0A=
altogether.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M.<BR><BR><BR>Florian =
Oelmaier =0A=
wrote:<BR>&gt; Your argument is "nonces are only for replay protection". =
Thats =0A=
true.<BR>&gt;<BR>&gt; Now lets discuss WHY a client wants to get replay =0A=
protection. Seeing<BR>&gt; that we have the three times in the response =
with a =0A=
clear semantic, the<BR>&gt; client is not harmed by a replay. So why =
should a =0A=
client include a nonce<BR>&gt; into the request?<BR>&gt;<BR>&gt; There =
are =0A=
different reasons for that, but the main reason is: the client<BR>&gt; =
wants a =0A=
"fresh" response. Following that path Ryans arguments apply as<BR>&gt; =
he =0A=
presented it in his previous replies. A client will include a =
nonce<BR>&gt; into =0A=
the request to ask for a "fresh" response. If the client does =
not<BR>&gt; need a =0A=
fresh response, then replaying is not a problem (then it is a<BR>&gt; =
feature =0A=
called "caching").<BR>&gt;<BR>&gt; So if a responder gets a request with =
a =0A=
nonce, it not only means "the<BR>&gt; client wants replay protection" - =
it also =0A=
means "the client would like<BR>&gt; to get a fresh response". Because =
otherwise =0A=
replay attacks would not<BR>&gt; =0A=
matter.<BR>&gt;<BR></P></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B554.1EC1C1FC--

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

Date: Thu, 27 Nov 2003 16:23:47 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

That's all fine.  Really!

But why would the client not care if the nonce is echoed in the response?

The client should only ask for a fresh response if it really wants one. 
To make frivolous requests for freshness would unnecessarily tax a 
server that actually cares and tries to fulfill the requests.

In the end, making the requirement anything less that "MUST reject" will 
lead to servers simply ignoring the nonce extension altogether.

		M.

Florian Oelmaier wrote:
> Your argument is "nonces are only for replay protection". Thats true.
> 
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, the
> client is not harmed by a replay. So why should a client include a nonce
> into the request?
> 
> There are different reasons for that, but the main reason is: the client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
> 
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
> 

--------------ms000405020605020409010402
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

--------------ms000405020605020409010402--

From: "Florian Oelmaier" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 01:14:55 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

Your argument is "nonces are only for replay protection". Thats true.

Now lets discuss WHY a client wants to get replay protection. Seeing
that we have the three times in the response with a clear semantic, the
client is not harmed by a replay. So why should a client include a nonce
into the request?

There are different reasons for that, but the main reason is: the client
wants a "fresh" response. Following that path Ryans arguments apply as
he presented it in his previous replies. A client will include a nonce
into the request to ask for a "fresh" response. If the client does not
need a fresh response, then replaying is not a problem (then it is a
feature called "caching").

So if a responder gets a request with a nonce, it not only means "the
client wants replay protection" - it also means "the client would like
to get a fresh response". Because otherwise replay attacks would not
matter.

-- 
Florian Oelmaier
SyTrust

Date: Thu, 27 Nov 2003 15:53:12 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Florian Oelmaier wrote:
> 
>>>I object. It breaks running code in installations.
>>
>>That code is not secure, and did not follow the spec.
> 
> Accept it or not, but even code not using nonces is secure! At least as
> secure as using CRLs. And definitely better than not checking revocation
> at all.

Yes, it is just as secure as using CRLs.  CRLs are also vulnerable to 
replay attacks.  OCSP has a mechanism - nonces - to thwart replay 
attacks.  Code that abuses (or just doesn't use) that mechanism is 
insecure against replay attacks.

> If we follow the path of your arguments, we should make nonce a
> requirement in OCSP.

Not at all.  Many environments are perfectly fine with the risk of 
replay attacks.

> Seeing the TLS OCSP extensions this renders OCSP
> unusable.

I don't see how that follows.

> If we agree that pre-produced responses are reasonable for
> some use-cases, then you cannot argue that code accepting nonce-less
> responses is not secure.

That's not my argument.  The crux is whether a nonce is in the request.

If the request as a nonce, then the response MUST echo the nonce and the 
client MUST reject a nonceless response.  Why?  Because nonces are how 
OCSP prevents replay attacks.  To act any other way fails to prevent 
replay attacks.

However, if the request does _not_ have a nonce, then the client is 
perfectly free to accept nonceless (or nonceful) responses.

> Most clients are concerned about replay attacks.

Not the ones that don't care about nonces in responses.

> But the first priority
> of an OCSP-client is to get secure revocation information (at least the
> same quality as a CRL). If the client is also able to get replay
> protection, fine!

If the client puts a nonce in a request and doesn't behave differently 
depending on the presence/absence of the nonce in the response, then why 
put the nonce in at all?

>>Nearly all protocols out there are insecure.  This is a security WG...
> 
> [A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
> security are not mutually exclusive.

Nonces are not a feature-fallback mechanism.  Nonces prevent replay 
attacks.  If you want feature-fallback, you need to carefully consider 
the mechanism(s) you use.  Overloading the use of nonces as OCSPv1 
progresses up the standards track is wrong, ill-advised and insecure.

		M.

--------------ms020802090503030700060305
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

--------------ms020802090503030700060305--

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 15:56:05 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B542.050B45F7"

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

cil

________________________________

From: [email-masked] on behalf of Marc Branchaud
Sent: Thu 11/27/2003 1:49 PM
To: [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1

Ryan M. Hurst wrote:
>
>> Why can't the client can decide this before making the request?
>
> [rmh] There are several cases; consider this one, bookstore.com
> (server) has a certificate from bigttp.com, client is connecting to
> bookstore.com and both the client and the server in this scenario
> support the new tls extensions allowing a server to provide a client
> a copy of its ocsp response (from bigttp.com). The server would want
> to keep a local copy of the ocsp response, he would also want to
> re-fresh this cached copy before passing it off to the client if he
> knew it was expired or about to be expired. He could when generating
> his OCSP request to bigttp.com include a nonce indicating he wants a
> fresh response (afterall this is implicit when asking for the nonce
> in the response). Since in this case all the server wants is a fresh
> response (he will be caching and replaying afterall) getting back a
> respone without a nonce is OK.

No, it's not OK.

First off, the nonce is _not_ an indication that the server wants a
fresh response.  Like the RFC says, it's an indication that the server
doesn't want to be replayed a previous response.  Even with the nonce,
there's nothing to stop the bigttp.com OCSP server from giving the
server a status value based on yesterday's CRL.
[rmh] Never said that was the explicit intent of the nonce, it is a side =
effect; even if bigttp.com gave a response that was based on a CRL it =
would still be the freshest response possible.

Second, if the server accepts a nonceless response not only is it not
guaranteeing that it gets a "fresh" response, but it's also at risk of
getting a replayed response.  Again, the nonce (or rather, its
absence/presence in the response) does nothing to guanrantee any kind of
"freshness".  By accepting nonceless responses the server could even
accept the same response it already has.  If the server's OK with that,
then there's no point in putting a nonce in the request in the first =
place.
[rmh] Replay is the goal in this scenario, e.g. intermediate caching so =
I am not sure I get your point. As to the guarantees in OCSP the only =
garontees in the protocol (asuming a accepted trust model) is that the =
status in the response given the constraints associated with it (time =
validity, etc.) are truthfull. My point in the scenario above (and I =
imagine this being a VERY common scenario) is that for the likley side =
effect of submiting a nonced request is that you will get the freshes =
informationa availible; no gaurantees but it incredibly likley.

> The alternative with the proposed text would be to make a request
> with the nonce, get denied and make another one; resulting in two
> wire retrievals instead of one like the original version of the RFC
> allowed for.

There's more than one alternative.

A more reasonable approach would for the server to not put a nonce in
the request in the first place.  This results in a single over-the-wire
transaction that meets the security parameters the server is willing to
live with.

[rmh] Sure, if you dont care about the scenario in question that would =
work; the front end server would likley be a pre-produced responder (and =
in this case that is very likley, espectialy if you wanted to scale to =
support internet scale revocation checking); the likley behavior if such =
a responder got a request with a nonce is that it would try to service =
it either by using its own key material to produce a fresh response or =
more likley forward the request to a back end server that would do just =
that.

>> What does the client gain by making a nonced request but accepting
>> a nonceless response?
>
> [rmh] there are several, consider the above; we must remember what
> the nonce means; directly it means I would like to try to protect
> myself from replays; ok, so what is a replay? a stale response; so it
> also means give me the freshest data you have.

No, it doesn't mean that at all.  The OCSP server is still free to
construct a response based on whatever data it sees fit.  All the nonce
does is force the server to sign a new response.  It doesn't say
anything about how "fresh" the data is in that response.

[rmh] I did not say it did, and in this case its not about guarantees.

> If the group wishes to address the use of nonces for more than replay
>  prevention, then I think the only option is to devise a new OCSPv2
> spec.
>
> [rmh] its not necesssary, the current RFC works and by changing the
> semantics you disallow a legitimate use that worked and was
> conformant.

But that use wasn't conformant.  All that RFC2560 wants to use nonces
for is to prevent replay attacks.  Any other use of nonces goes beyond
what RFC2560 says they're for.

[rmh] it absolutley is; find the text that precludes this behavior.

                M.

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>Re: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText95022 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>cil</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Thu 11/27/2003 1:49 PM<BR><B>To:</B> =0A=
[email-masked]<BR><B>Subject:</B> Re: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Ryan M. Hurst wrote:<BR>&gt;<BR>&gt;&gt; Why can't the =
client =0A=
can decide this before making the request?<BR>&gt;<BR>&gt; [rmh] There =
are =0A=
several cases; consider this one, bookstore.com<BR>&gt; (server) has a =0A=
certificate from bigttp.com, client is connecting to<BR>&gt; =
bookstore.com and =0A=
both the client and the server in this scenario<BR>&gt; support the new =
tls =0A=
extensions allowing a server to provide a client<BR>&gt; a copy of its =
ocsp =0A=
response (from bigttp.com). The server would want<BR>&gt; to keep a =
local copy =0A=
of the ocsp response, he would also want to<BR>&gt; re-fresh this cached =
copy =0A=
before passing it off to the client if he<BR>&gt; knew it was expired or =
about =0A=
to be expired. He could when generating<BR>&gt; his OCSP request to =
bigttp.com =0A=
include a nonce indicating he wants a<BR>&gt; fresh response (afterall =
this is =0A=
implicit when asking for the nonce<BR>&gt; in the response). Since in =
this case =0A=
all the server wants is a fresh<BR>&gt; response (he will be caching and =0A=
replaying afterall) getting back a<BR>&gt; respone without a nonce is =0A=
OK.<BR><BR>No, it's not OK.<BR><BR>First off, the nonce is _not_ an =
indication =0A=
that the server wants a<BR>fresh response.&nbsp; Like the RFC says, it's =
an =0A=
indication that the server<BR>doesn't want to be replayed a previous =0A=
response.&nbsp; Even with the nonce,<BR>there's nothing to stop the =
bigttp.com =0A=
OCSP server from giving the<BR>server a status value based on =
yesterday's =0A=
CRL.<BR>[rmh] Never said that was the explicit intent of the nonce, it =
is a side =0A=
effect; even if bigttp.com gave a response that was based on a CRL it =
would =0A=
still be the freshest response possible.</FONT></P><FONT size=3D2>=0A=
<P><BR>Second, if the server accepts a nonceless response not only is it =0A=
not<BR>guaranteeing that it gets a "fresh" response, but it's also at =
risk =0A=
of<BR>getting a replayed response.&nbsp; Again, the nonce (or rather, =0A=
its<BR>absence/presence in the response) does nothing to guanrantee any =
kind =0A=
of<BR>"freshness".&nbsp; By accepting nonceless responses the server =
could =0A=
even<BR>accept the same response it already has.&nbsp; If the server's =
OK with =0A=
that,<BR>then there's no point in putting a nonce in the request in the =
first =0A=
place.<BR>[rmh] Replay is the goal in this scenario, e.g. intermediate =
caching =0A=
so I am not sure I get your point. As to the guarantees in OCSP the only =0A=
garontees in the protocol (asuming a accepted trust model) is that =0A=
the&nbsp;status in the response given the constraints associated with it =
(time =0A=
validity, etc.) are truthfull. My point in the scenario above (and I =
imagine =0A=
this being a VERY common scenario) is that for the likley side effect of =0A=
submiting a nonced request is that you will get the freshes informationa =0A=
availible; no gaurantees but it incredibly likley.</P>=0A=
<P><BR>&gt; The alternative with the proposed text would be to make a =0A=
request<BR>&gt; with the nonce, get denied and make another one; =
resulting in =0A=
two<BR>&gt; wire retrievals instead of one like the original version of =
the =0A=
RFC<BR>&gt; allowed for.<BR><BR>There's more than one =
alternative.<BR><BR>A more =0A=
reasonable approach would for the server to not put a nonce in<BR>the =
request in =0A=
the first place.&nbsp; This results in a single =
over-the-wire<BR>transaction =0A=
that meets the security parameters the server is willing to<BR>live =
with.</P>=0A=
<P>[rmh] Sure, if you dont care about the scenario in question that =
would work; =0A=
the front end server would likley be&nbsp;a pre-produced responder (and =
in this =0A=
case that is very likley, espectialy if you wanted to scale to support =
internet =0A=
scale revocation checking); the likley behavior if such a responder got =
a =0A=
request with a nonce is that it would try to service it either by using =
its own =0A=
key material to produce a fresh response or more likley forward the =
request to a =0A=
back end server that would do just that.<BR><BR>&gt;&gt; What does the =
client =0A=
gain by making a nonced request but accepting<BR>&gt;&gt; a nonceless =0A=
response?<BR>&gt;<BR>&gt; [rmh] there are several, consider the above; =
we must =0A=
remember what<BR>&gt; the nonce means; directly it means I would like to =
try to =0A=
protect<BR>&gt; myself from replays; ok, so what is a replay? a stale =
response; =0A=
so it<BR>&gt; also means give me the freshest data you have.<BR><BR>No, =
it =0A=
doesn't mean that at all.&nbsp; The OCSP server is still free =
to<BR>construct a =0A=
response based on whatever data it sees fit.&nbsp; All the nonce<BR>does =
is =0A=
force the server to sign a new response.&nbsp; It doesn't =
say<BR>anything about =0A=
how "fresh" the data is in that response.</P>=0A=
<P>[rmh] I did not say it did, and in this case its not about =0A=
guarantees.<BR><BR><BR>&gt; If the group wishes to address the use of =
nonces for =0A=
more than replay<BR>&gt;&nbsp; prevention, then I think the only option =
is to =0A=
devise a new OCSPv2<BR>&gt; spec.<BR>&gt;<BR>&gt; [rmh] its not =
necesssary, the =0A=
current RFC works and by changing the<BR>&gt; semantics you disallow a =0A=
legitimate use that worked and was<BR>&gt; conformant.<BR><BR>But that =
use =0A=
wasn't conformant.&nbsp; All that RFC2560 wants to use nonces<BR>for is =
to =0A=
prevent replay attacks.&nbsp; Any other use of nonces goes =
beyond<BR>what =0A=
RFC2560 says they're for.</P>=0A=
<P>[rmh] it absolutley is; find the text that precludes this =0A=
behavior.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
M.<BR></P></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B542.050B45F7--

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

From: "Florian Oelmaier" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 00:38:13 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

Hello Marc,

> > I object. It breaks running code in installations.
> 
> That code is not secure, and did not follow the spec.

Accept it or not, but even code not using nonces is secure! At least as
secure as using CRLs. And definitely better than not checking revocation
at all.

If we follow the path of your arguments, we should make nonce a
requirement in OCSP. Seeing the TLS OCSP extensions this renders OCSP
unusable. If we agree that pre-produced responses are reasonable for
some use-cases, then you cannot argue that code accepting nonce-less
responses is not secure.

> > Seeing this it is a very acceptable for a client to TRY to get a 
> > nonce, but to accept answers without nonces as a fallback.
> 
> No, it is not acceptable.  The RFC is very clear: use nonces 
> to prevent 
> replay attacks.  If the client is concerned about replay attacks, it 
> must reject a nonceless response.

Most clients are concerned about replay attacks. But the first priority
of an OCSP-client is to get secure revocation information (at least the
same quality as a CRL). If the client is also able to get replay
protection, fine!

> > It is a "natural"
> > behaviour - I try for all extensions I support, but will 
> fall back to 
> > the very basics of the standard, to the "not extended" 
> behaviour when 
> > I cannot get what I want. This is the usual way of doing things in 
> > nearly all protocols out there, PKIX or not.
> 
> Nearly all protocols out there are insecure.  This is a security WG...

[A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
security are not mutually exclusive.

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 00:26:07 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

I love it. It will be implemented as soon as possible in our client and
server.

This also opens up a lot of very valuable use-cases in combination with
the TLS OCSP extension!

-- 
Florian Oelmaier
SyTrust

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 9:32 PM
> To: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> 
> If anyone objects to the path forward as discussed below, 
> please speak up now.  Concurrence is equally welcome.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of David Engberg
> > Sent: Thursday, November 27, 2003 12:46 PM
> > To: Michael Myers
> > Cc: [email-masked]
> > Subject: Re: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> >
> > Exactly.  I'd implement this right now if I wasn't so
> > full of turkey.
> >
> >
> > Michael Myers wrote:
> > >
> > > Understand your caching servers MUST send back a caveated 
> response 
> > > which by presence of the caveat may or may not be 
> accepted.  No fair 
> > > sending back plain ones, errors notwithstanding.  Is this 
> > > understood?
> > >
> > > Mike
> > >
> > >
> > >>-----Original Message-----
> > >>From: David Engberg [mailto:[email-masked]]
> > >>Sent: Thursday, November 27, 2003 12:25 PM
> > >>To: Michael Myers
> > >>Cc: [email-masked]
> > >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> > >>
> > >>
> > >>
> > >>I'd add "or return an error [e.g. unauthorized?]" to
> > >>the end of '4' (to
> > >>remain compliant in the presence of requests for
> > >>unknown certs), but it
> > >>is otherwise my dream scenario.
> > >>
> > >>
> > >>Michael Myers wrote:
> > >>
> > >>>Dave,
> > >>>
> > >>>So how about:
> > >>>
> > >>>1. If we can cycle v1 at Proposed (a big if); then
> > >>>
> > >>>2. Define nonceUnsupported extension subject to
> > >>>   the following semantics (I'm squeezing the
> > >>>   words a bit but you'll get the drift)
> > >>>
> > >>>3. Clients that send a nonce:
> > >>>
> > >>>   a. MUST reject a non-nonced response
> > >>>      if that response includes either the
> > >>>      value "good" or "revoked" AND it fails
> > >>>      to include the nonceUnsupported extension;
> > >>>
> > >>>   b. Else, if such response includes the
> > >>>      nonceUnsupported extension, clients
> > >>>      MAY accept the response subject to the
> > >>>      advice in the Security Considerations
> > >>>      section of this document.
> > >>>
> > >>>4. Conversely, if a server receives a nonced
> > >>>   request but is unable to incorporate the
> > >>>   nonce in its response, the server MUST
> > >>>   include the nonceUnsupported extension.
> > >>>
> > >>> Note that I made no distinction between "good",
> > >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> > >>> a plain nonceless response of "good" or
> > >>> "revoked" is non-conformant, while a caveated
> > >>> response is subject to the client's local
> > >>> security policy.
> > >>>
> > >>> Does this seem a fair compromise?  Note well it's 
> highly dependent 
> > >>> on cycling v1 at Proposed.
> > >>>
> > >>> Mike
> > >
> > >
> > >
> >
> 
> 

Date: Thu, 27 Nov 2003 15:02:58 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Michael Myers wrote:
> 
> If anyone objects to the path forward as discussed below, please
> speak up now.  Concurrence is equally welcome.

I'm indifferent to cycling at Proposed.

I'm not convinced that nonceUnsupported is needed at all.  It seems 
exactly the kind of baroque bloat PKIX is famous for (not that I have 
any new reason for the group to break with that tradition).

		M.

--------------ms000801070905090402020205
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

--------------ms000801070905090402020205--

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 14:21:12 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B534.F77A19EA"

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

I do not support this change for all the reasons called out previously.
=20
Ryan

________________________________

From: [email-masked] on behalf of Michael Myers
Sent: Thu 11/27/2003 12:31 PM
To: [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

If anyone objects to the path forward as discussed below, please
speak up now.  Concurrence is equally welcome.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Thursday, November 27, 2003 12:46 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> Exactly.  I'd implement this right now if I wasn't so
> full of turkey.
>
>
> Michael Myers wrote:
> >
> > Understand your caching servers MUST send back a caveated
> > response which by presence of the caveat may or may not be
> > accepted.  No fair sending back plain ones, errors
> > notwithstanding.  Is this understood?
> >
> > Mike
> >
> >
> >>-----Original Message-----
> >>From: David Engberg [mailto:[email-masked]]
> >>Sent: Thursday, November 27, 2003 12:25 PM
> >>To: Michael Myers
> >>Cc: [email-masked]
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>I'd add "or return an error [e.g. unauthorized?]" to
> >>the end of '4' (to
> >>remain compliant in the presence of requests for
> >>unknown certs), but it
> >>is otherwise my dream scenario.
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Dave,
> >>>
> >>>So how about:
> >>>
> >>>1. If we can cycle v1 at Proposed (a big if); then
> >>>
> >>>2. Define nonceUnsupported extension subject to
> >>>   the following semantics (I'm squeezing the
> >>>   words a bit but you'll get the drift)
> >>>
> >>>3. Clients that send a nonce:
> >>>
> >>>   a. MUST reject a non-nonced response
> >>>      if that response includes either the
> >>>      value "good" or "revoked" AND it fails
> >>>      to include the nonceUnsupported extension;
> >>>
> >>>   b. Else, if such response includes the
> >>>      nonceUnsupported extension, clients
> >>>      MAY accept the response subject to the
> >>>      advice in the Security Considerations
> >>>      section of this document.
> >>>
> >>>4. Conversely, if a server receives a nonced
> >>>   request but is unable to incorporate the
> >>>   nonce in its response, the server MUST
> >>>   include the nonceUnsupported extension.
> >>>
> >>> Note that I made no distinction between "good",
> >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> >>> a plain nonceless response of "good" or
> >>> "revoked" is non-conformant, while a caveated
> >>> response is subject to the client's local
> >>> security policy.
> >>>
> >>> Does this seem a fair compromise?  Note well it's highly
> >>> dependent on cycling v1 at Proposed.
> >>>
> >>> Mike
> >
> >
> >
>

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>RE: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText33778 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I do not =
support this change =0A=
for all the reasons called out previously.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of =0A=
Michael Myers<BR><B>Sent:</B> Thu 11/27/2003 12:31 PM<BR><B>To:</B> =0A=
[email-masked]<BR><B>Subject:</B> RE: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV><BR><BR>=0A=
<P><FONT size=3D2>If anyone objects to the path forward as discussed =
below, =0A=
please<BR>speak up now.&nbsp; Concurrence is equally =0A=
welcome.<BR><BR>Mike<BR><BR><BR>&gt; -----Original Message-----<BR>&gt; =
From: =0A=
[email-masked]<BR>&gt; [<A =0A=
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]On =0A=
Behalf Of<BR>&gt; David Engberg<BR>&gt; Sent: Thursday, November 27, =
2003 12:46 =0A=
PM<BR>&gt; To: Michael Myers<BR>&gt; Cc: [email-masked]<BR>&gt; =
Subject: Re: =0A=
DISCUSS: MUST reject in OCSPv1<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; =0A=
Exactly.&nbsp; I'd implement this right now if I wasn't so<BR>&gt; full =
of =0A=
turkey.<BR>&gt;<BR>&gt;<BR>&gt; Michael Myers wrote:<BR>&gt; =
&gt;<BR>&gt; &gt; =0A=
Understand your caching servers MUST send back a caveated<BR>&gt; &gt; =
response =0A=
which by presence of the caveat may or may not be<BR>&gt; &gt; =
accepted.&nbsp; =0A=
No fair sending back plain ones, errors<BR>&gt; &gt; =
notwithstanding.&nbsp; Is =0A=
this understood?<BR>&gt; &gt;<BR>&gt; &gt; Mike<BR>&gt; &gt;<BR>&gt; =0A=
&gt;<BR>&gt; &gt;&gt;-----Original Message-----<BR>&gt; &gt;&gt;From: =
David =0A=
Engberg [<A =0A=
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>&g=
t; =0A=
&gt;&gt;Sent: Thursday, November 27, 2003 12:25 PM<BR>&gt; &gt;&gt;To: =
Michael =0A=
Myers<BR>&gt; &gt;&gt;Cc: [email-masked]<BR>&gt; &gt;&gt;Subject: Re: =0A=
DISCUSS: MUST reject in OCSPv1<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =0A=
&gt;&gt;<BR>&gt; &gt;&gt;I'd add "or return an error [e.g. =
unauthorized?]" =0A=
to<BR>&gt; &gt;&gt;the end of '4' (to<BR>&gt; &gt;&gt;remain compliant =
in the =0A=
presence of requests for<BR>&gt; &gt;&gt;unknown certs), but it<BR>&gt; =0A=
&gt;&gt;is otherwise my dream scenario.<BR>&gt; &gt;&gt;<BR>&gt; =0A=
&gt;&gt;<BR>&gt; &gt;&gt;Michael Myers wrote:<BR>&gt; &gt;&gt;<BR>&gt; =0A=
&gt;&gt;&gt;Dave,<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;So how =
about:<BR>&gt; =0A=
&gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;1. If we can cycle v1 at Proposed (a =
big if); =0A=
then<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;2. Define nonceUnsupported =0A=
extension subject to<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; the following =
semantics =0A=
(I'm squeezing the<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; words a bit but =
you'll get =0A=
the drift)<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;3. Clients that send =
a =0A=
nonce:<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; a. MUST =
reject a =0A=
non-nonced response<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
if that =0A=
response includes either the<BR>&gt; =
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
value "good" or "revoked" AND it fails<BR>&gt; =0A=
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to include the =
nonceUnsupported =0A=
extension;<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; b. =
Else, if =0A=
such response includes the<BR>&gt; =
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
nonceUnsupported extension, clients<BR>&gt; =0A=
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MAY accept the response =
subject to =0A=
the<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; advice in the =
Security =0A=
Considerations<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
section of =0A=
this document.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;4. Conversely, =
if a =0A=
server receives a nonced<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; request but is =
unable =0A=
to incorporate the<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; nonce in its =
response, the =0A=
server MUST<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; include the =
nonceUnsupported =0A=
extension.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Note that I made no =0A=
distinction between "good",<BR>&gt; &gt;&gt;&gt; "revoked" or "unknown" =
in #3.b =0A=
or #4.&nbsp; Thus,<BR>&gt; &gt;&gt;&gt; a plain nonceless response of =
"good" =0A=
or<BR>&gt; &gt;&gt;&gt; "revoked" is non-conformant, while a =
caveated<BR>&gt; =0A=
&gt;&gt;&gt; response is subject to the client's local<BR>&gt; =
&gt;&gt;&gt; =0A=
security policy.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Does this =
seem a fair =0A=
compromise?&nbsp; Note well it's highly<BR>&gt; &gt;&gt;&gt; dependent =
on =0A=
cycling v1 at Proposed.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; =
Mike<BR>&gt; =0A=
&gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt;<BR><BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B534.F77A19EA--

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

Date: Thu, 27 Nov 2003 13:49:36 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Ryan M. Hurst wrote:
> 
>> Why can't the client can decide this before making the request?
> 
> [rmh] There are several cases; consider this one, bookstore.com
> (server) has a certificate from bigttp.com, client is connecting to
> bookstore.com and both the client and the server in this scenario
> support the new tls extensions allowing a server to provide a client
> a copy of its ocsp response (from bigttp.com). The server would want
> to keep a local copy of the ocsp response, he would also want to
> re-fresh this cached copy before passing it off to the client if he
> knew it was expired or about to be expired. He could when generating
> his OCSP request to bigttp.com include a nonce indicating he wants a
> fresh response (afterall this is implicit when asking for the nonce
> in the response). Since in this case all the server wants is a fresh
> response (he will be caching and replaying afterall) getting back a
> respone without a nonce is OK.

No, it's not OK.

First off, the nonce is _not_ an indication that the server wants a
fresh response.  Like the RFC says, it's an indication that the server
doesn't want to be replayed a previous response.  Even with the nonce,
there's nothing to stop the bigttp.com OCSP server from giving the
server a status value based on yesterday's CRL.

Second, if the server accepts a nonceless response not only is it not
guaranteeing that it gets a "fresh" response, but it's also at risk of
getting a replayed response.  Again, the nonce (or rather, its
absence/presence in the response) does nothing to guanrantee any kind of
"freshness".  By accepting nonceless responses the server could even
accept the same response it already has.  If the server's OK with that,
then there's no point in putting a nonce in the request in the first place.

> The alternative with the proposed text would be to make a request
> with the nonce, get denied and make another one; resulting in two
> wire retrievals instead of one like the original version of the RFC
> allowed for.

There's more than one alternative.

A more reasonable approach would for the server to not put a nonce in
the request in the first place.  This results in a single over-the-wire
transaction that meets the security parameters the server is willing to
live with.

>> What does the client gain by making a nonced request but accepting
>> a nonceless response?
> 
> [rmh] there are several, consider the above; we must remember what
> the nonce means; directly it means I would like to try to protect
> myself from replays; ok, so what is a replay? a stale response; so it
> also means give me the freshest data you have.

No, it doesn't mean that at all.  The OCSP server is still free to
construct a response based on whatever data it sees fit.  All the nonce
does is force the server to sign a new response.  It doesn't say
anything about how "fresh" the data is in that response.

> If the group wishes to address the use of nonces for more than replay
>  prevention, then I think the only option is to devise a new OCSPv2
> spec.
> 
> [rmh] its not necesssary, the current RFC works and by changing the 
> semantics you disallow a legitimate use that worked and was
> conformant.

But that use wasn't conformant.  All that RFC2560 wants to use nonces
for is to prevent replay attacks.  Any other use of nonces goes beyond
what RFC2560 says they're for.

		M.

--------------ms070402050606080700050908
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

--------------ms070402050606080700050908--

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 13:21:44 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B52C.750AC865"

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

cil

________________________________

From: [email-masked] on behalf of Marc Branchaud
Sent: Thu 11/27/2003 10:40 AM
To: [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1

Ryan M. Hurst wrote:
> I don't think its silly, the client is still protected from the replay
> if the server responds to a nonced request with a un-nonced one as the
> client can decide decide if he wanted the protection or needed it.

Why can't the client can decide this before making the request?

[rmh] There are several cases; consider this one, bookstore.com (server) =
has a certificate from bigttp.com, client is connecting to bookstore.com =
and both the client and the server in this scenario support the new tls =
extensions allowing a server to provide a client a copy of its ocsp =
response (from bigttp.com). The server would want to keep a local copy =
of the ocsp response, he would also want to re-fresh this cached copy =
before passing it off to the client if he knew it was expired or about =
to be expired. He could when generating his OCSP request to bigttp.com =
include a nonce indicating he wants a fresh response (afterall this is =
implicit when asking for the nonce in the response). Since in this case =
all the server wants is a fresh response (he will be caching and =
replaying afterall) getting back a respone without a nonce is OK. The =
alternative with the proposed text would be to make a request with the =
nonce, get denied and make another one; resulting in two wire retrievals =
instead of one like the original version of the RFC allowed for.

What does the client gain by making a nonced request but accepting a
nonceless response?
[rmh] there are several, consider the above; we must remember what the =
nonce means; directly it means I would like to try to protect myself =
from replays; ok, so what is a replay? a stale response; so it also =
means give me the freshest data you have.

> That may sound strange, but nonce has other implications that re-play
> protection; it also implies freshness since pre-produced responses can
> not have the right nonce in it.

If the group wishes to address the use of nonces for more than replay
prevention, then I think the only option is to devise a new OCSPv2 spec.

[rmh] its not necesssary, the current RFC works and by changing the =
semantics you disallow a legitimate use that worked and was conformant.

                M.

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>Re: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText77547 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>cil</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Thu 11/27/2003 10:40 AM<BR><B>To:</B> =0A=
[email-masked]<BR><B>Subject:</B> Re: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Ryan M. Hurst wrote:<BR>&gt; I don't think its silly, =
the client =0A=
is still protected from the replay<BR>&gt; if the server responds to a =
nonced =0A=
request with a un-nonced one as the<BR>&gt; client can decide decide if =
he =0A=
wanted the protection or needed it.<BR><BR>Why can't the client can =
decide this =0A=
before making the request?<BR></FONT></P>=0A=
<P><FONT size=3D2>[rmh] There are several cases; consider this one, =
bookstore.com =0A=
(server) has a certificate from bigttp.com, client is connecting to =0A=
bookstore.com and both the client and the server in this scenario =
support the =0A=
new tls extensions allowing a server to provide a client a copy of its =
ocsp =0A=
response (from bigttp.com). The server would want to keep a local copy =
of the =0A=
ocsp response, he would also want to re-fresh this cached copy before =
passing it =0A=
off to the client if he knew it was expired or about to be expired. He =
could =0A=
when generating his OCSP request to bigttp.com include a nonce =
indicating he =0A=
wants a fresh response (afterall this is implicit when asking for the =
nonce in =0A=
the response). Since in this case all the server wants is a fresh =
response (he =0A=
will be caching and replaying afterall) getting back a respone without a =
nonce =0A=
is OK. The alternative with the proposed text would be to make a request =
with =0A=
the nonce, get denied and make another one; resulting in two wire =
retrievals =0A=
instead of one like the original version of the RFC allowed =
for.</FONT></P><FONT =0A=
size=3D2>=0A=
<P><BR>What does the client gain by making a nonced request but =
accepting =0A=
a<BR>nonceless response?<BR>[rmh] there are several, consider the above; =
we must =0A=
remember what the nonce means; directly it means I would like to try to =
protect =0A=
myself from replays; ok, so what is a replay? a stale response; so it =
also means =0A=
give me the freshest data you have.</P>=0A=
<P><BR>&gt; That may sound strange, but nonce has other implications =
that =0A=
re-play<BR>&gt; protection; it also implies freshness since pre-produced =0A=
responses can<BR>&gt; not have the right nonce in it.<BR><BR>If the =
group wishes =0A=
to address the use of nonces for more than replay<BR>prevention, then I =
think =0A=
the only option is to devise a new OCSPv2 spec.</P>=0A=
<P>[rmh] its not necesssary, the current RFC works and by changing the =
semantics =0A=
you&nbsp;disallow a legitimate use that worked and was =0A=
conformant.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
M.<BR></P></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B52C.750AC865--

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

Date: Thu, 27 Nov 2003 16:44:53 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Peter Gutmann wrote:
> consumer protection legislation,

I'm not a lawyer and the terms are for sure used much differently in other
countries. But I also guess that most ToS-style CPs would not withstand a
court trial based on german AGB-Gesetz, the law regulating "Allgemeine
Gesch�ftsbedingungen" (similar to ToS).

But since PKI did not hit the mass market yet a CA with such a ToS-style CP
can assume that this risk is quite low.
Less RPs => less serious usage => less risks. ;-)

Ciao, Michael.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 13:31:40 -0700
Importance: Normal
Sender: [email-masked]

If anyone objects to the path forward as discussed below, please
speak up now.  Concurrence is equally welcome.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Thursday, November 27, 2003 12:46 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> Exactly.  I'd implement this right now if I wasn't so
> full of turkey.
>
>
> Michael Myers wrote:
> >
> > Understand your caching servers MUST send back a caveated
> > response which by presence of the caveat may or may not be
> > accepted.  No fair sending back plain ones, errors
> > notwithstanding.  Is this understood?
> >
> > Mike
> >
> >
> >>-----Original Message-----
> >>From: David Engberg [mailto:[email-masked]]
> >>Sent: Thursday, November 27, 2003 12:25 PM
> >>To: Michael Myers
> >>Cc: [email-masked]
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>I'd add "or return an error [e.g. unauthorized?]" to
> >>the end of '4' (to
> >>remain compliant in the presence of requests for
> >>unknown certs), but it
> >>is otherwise my dream scenario.
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Dave,
> >>>
> >>>So how about:
> >>>
> >>>1. If we can cycle v1 at Proposed (a big if); then
> >>>
> >>>2. Define nonceUnsupported extension subject to
> >>>   the following semantics (I'm squeezing the
> >>>   words a bit but you'll get the drift)
> >>>
> >>>3. Clients that send a nonce:
> >>>
> >>>   a. MUST reject a non-nonced response
> >>>      if that response includes either the
> >>>      value "good" or "revoked" AND it fails
> >>>      to include the nonceUnsupported extension;
> >>>
> >>>   b. Else, if such response includes the
> >>>      nonceUnsupported extension, clients
> >>>      MAY accept the response subject to the
> >>>      advice in the Security Considerations
> >>>      section of this document.
> >>>
> >>>4. Conversely, if a server receives a nonced
> >>>   request but is unable to incorporate the
> >>>   nonce in its response, the server MUST
> >>>   include the nonceUnsupported extension.
> >>>
> >>> Note that I made no distinction between "good",
> >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> >>> a plain nonceless response of "good" or
> >>> "revoked" is non-conformant, while a caveated
> >>> response is subject to the client's local
> >>> security policy.
> >>>
> >>> Does this seem a fair compromise?  Note well it's highly
> >>> dependent on cycling v1 at Proposed.
> >>>
> >>> Mike
> >
> >
> >
>

Date: Thu, 27 Nov 2003 14:45:57 -0500
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

Exactly.  I'd implement this right now if I wasn't so full of turkey.

Michael Myers wrote:
> 
> Understand your caching servers MUST send back a caveated
> response which by presence of the caveat may or may not be
> accepted.  No fair sending back plain ones, errors
> notwithstanding.  Is this understood?
> 
> Mike
> 
> 
>>-----Original Message-----
>>From: David Engberg [mailto:[email-masked]]
>>Sent: Thursday, November 27, 2003 12:25 PM
>>To: Michael Myers
>>Cc: [email-masked]
>>Subject: Re: DISCUSS: MUST reject in OCSPv1
>>
>>
>>
>>I'd add "or return an error [e.g. unauthorized?]" to
>>the end of '4' (to
>>remain compliant in the presence of requests for
>>unknown certs), but it
>>is otherwise my dream scenario.
>>
>>
>>Michael Myers wrote:
>>
>>>Dave,
>>>
>>>So how about:
>>>
>>>1. If we can cycle v1 at Proposed (a big if); then
>>>
>>>2. Define nonceUnsupported extension subject to
>>>   the following semantics (I'm squeezing the
>>>   words a bit but you'll get the drift)
>>>
>>>3. Clients that send a nonce:
>>>
>>>   a. MUST reject a non-nonced response
>>>      if that response includes either the
>>>      value "good" or "revoked" AND it fails
>>>      to include the nonceUnsupported extension;
>>>
>>>   b. Else, if such response includes the
>>>      nonceUnsupported extension, clients
>>>      MAY accept the response subject to the
>>>      advice in the Security Considerations
>>>      section of this document.
>>>
>>>4. Conversely, if a server receives a nonced
>>>   request but is unable to incorporate the
>>>   nonce in its response, the server MUST
>>>   include the nonceUnsupported extension.
>>>
>>>Note that I made no distinction between "good", "revoked" or
>>>"unknown" in #3.b or #4.  Thus, a plain nonceless
>>
>>response of
>>
>>>"good" or "revoked" is non-conformant, while a
>>
>>caveated response
>>
>>>is subject to the client's local security policy.
>>>
>>>Does this seem a fair compromise?  Note well it's highly
>>>dependent on cycling v1 at Proposed.
>>>
>>>Mike
> 
> 
> 

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 12:41:33 -0700
Importance: Normal
Sender: [email-masked]

Understand your caching servers MUST send back a caveated
response which by presence of the caveat may or may not be
accepted.  No fair sending back plain ones, errors
notwithstanding.  Is this understood?

Mike

> -----Original Message-----
> From: David Engberg [mailto:[email-masked]]
> Sent: Thursday, November 27, 2003 12:25 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
> I'd add "or return an error [e.g. unauthorized?]" to
> the end of '4' (to
> remain compliant in the presence of requests for
> unknown certs), but it
> is otherwise my dream scenario.
>
>
> Michael Myers wrote:
> > Dave,
> >
> > So how about:
> >
> > 1. If we can cycle v1 at Proposed (a big if); then
> >
> > 2. Define nonceUnsupported extension subject to
> >    the following semantics (I'm squeezing the
> >    words a bit but you'll get the drift)
> >
> > 3. Clients that send a nonce:
> >
> >    a. MUST reject a non-nonced response
> >       if that response includes either the
> >       value "good" or "revoked" AND it fails
> >       to include the nonceUnsupported extension;
> >
> >    b. Else, if such response includes the
> >       nonceUnsupported extension, clients
> >       MAY accept the response subject to the
> >       advice in the Security Considerations
> >       section of this document.
> >
> > 4. Conversely, if a server receives a nonced
> >    request but is unable to incorporate the
> >    nonce in its response, the server MUST
> >    include the nonceUnsupported extension.
> >
> > Note that I made no distinction between "good", "revoked" or
> > "unknown" in #3.b or #4.  Thus, a plain nonceless
> response of
> > "good" or "revoked" is non-conformant, while a
> caveated response
> > is subject to the client's local security policy.
> >
> > Does this seem a fair compromise?  Note well it's highly
> > dependent on cycling v1 at Proposed.
> >
> > Mike

Date: Thu, 27 Nov 2003 14:24:40 -0500
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

I'd add "or return an error [e.g. unauthorized?]" to the end of '4' (to 
remain compliant in the presence of requests for unknown certs), but it 
is otherwise my dream scenario.

Michael Myers wrote:
> Dave,
> 
> So how about:
> 
> 1. If we can cycle v1 at Proposed (a big if); then
> 
> 2. Define nonceUnsupported extension subject to
>    the following semantics (I'm squeezing the
>    words a bit but you'll get the drift)
> 
> 3. Clients that send a nonce:
> 
>    a. MUST reject a non-nonced response
>       if that response includes either the
>       value "good" or "revoked" AND it fails
>       to include the nonceUnsupported extension;
> 
>    b. Else, if such response includes the
>       nonceUnsupported extension, clients
>       MAY accept the response subject to the
>       advice in the Security Considerations
>       section of this document.
> 
> 4. Conversely, if a server receives a nonced
>    request but is unable to incorporate the
>    nonce in its response, the server MUST
>    include the nonceUnsupported extension.
> 
> Note that I made no distinction between "good", "revoked" or
> "unknown" in #3.b or #4.  Thus, a plain nonceless response of
> "good" or "revoked" is non-conformant, while a caveated response
> is subject to the client's local security policy.
> 
> Does this seem a fair compromise?  Note well it's highly
> dependent on cycling v1 at Proposed.
> 
> Mike
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: David Engberg [mailto:[email-masked]]
>>Sent: Thursday, November 27, 2003 10:58 AM
>>To: Michael Myers
>>Cc: [email-masked]
>>Subject: Re: DISCUSS: MUST reject in OCSPv1
>>
>>
>>
>>
>>Michael Myers wrote:
>>
>>>There's a chance we maybe can if we reset 2560 back
>>
>>to Proposed,
>>
>>>still call it v1 and let it cycle there for a
>>
>>while.  I've yet
>>
>>>to hear back from Russ on that one so I've been reluctant to
>>>play that card.  I think what will be the
>>
>>determining factor on
>>
>>>that potential course of action is if we can all
>>
>>agree on the
>>
>>>technical content.  The number of implementors who would be
>>>affected is still quite manageable.
>>
>>This sounds good to me.
>>
>>
>>
>>>I suspect though there still will remain the core issue:
>>>whether or not it is conformant in principle and in
>>
>>the spirit
>>
>>>of the RFC to send a nonceless response to a nonced
>>
>>request.  I
>>
>>>would further refine that by saying any nonceless signed
>>>response containing either "good" or "revoked".  I
>>
>>could accept
>>
>>>"unknown" due to reasons of nonces not being supported as
>>>indicated by a small extension to the protocol.
>>
>>I read the nonce description in the RFC as the client
>>asking for
>>something that it WANTS as opposed to demanding
>>something that it NEEDS.
>>  I.e. a nonce is one element in a list of things
>>like nextUpdate,
>>thisUpdate, producedAt, etc. that a client may use to
>>decide on response
>>acceptance based on the local security policy.
>>
>>The local policy needs to take all of these factors
>>into account, and
>>the absence/presence of a nonce is one factor which
>>may help avoid a
>>specific type of attack.  The default, recommended,
>>behavior is that a
>>nonceless response should be rejected unless the
>>client has a darned
>>good reason for accepting the response based on other
>>factors (e.g. the
>>response comes with a signed letter from the cert's
>>issuer saying it is
>>safe [safer, IMHO, but that's a separate discussion]
>>to accept the
>>nonceless response for its certs).
>>
>>It sounds like your interpretation is that the
>>presence of a nonce is
>>something the client NEEDS and that nonce absence
>>supercedes all other
>>policy considerations.  I don't think this is a
>>horrible interpretation,
>>but it does imply some limitations, as discussed.
>>
>>
> 
> 
> 

Date: Thu, 27 Nov 2003 10:40:35 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Ryan M. Hurst wrote:
> I don't think its silly, the client is still protected from the replay 
> if the server responds to a nonced request with a un-nonced one as the 
> client can decide decide if he wanted the protection or needed it.

Why can't the client can decide this before making the request?

What does the client gain by making a nonced request but accepting a 
nonceless response?

> That may sound strange, but nonce has other implications that re-play 
> protection; it also implies freshness since pre-produced responses can 
> not have the right nonce in it.

If the group wishes to address the use of nonces for more than replay 
prevention, then I think the only option is to devise a new OCSPv2 spec.

		M.

--------------ms040208080905030407040303
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

--------------ms040208080905030407040303--

Date: Thu, 27 Nov 2003 10:37:33 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

I support Mike's proposal to add "MUST reject" language to v1.  I am 
also fine with the idea of holding back OCSP and crafting a v2 to 
address people's concerns.

Rationale: RFC2560 explicitly states that nonces are used "to prevent 
replay attacks."  The RFC couldn't be more clear.  In order to prevent a 
replay attack, standard security practice is for a client to include a 
nonce in a request and to reject a response that does not echo the nonce.

Therefore, "MUST reject" is completely in line with the original RFC's 
use of the nonce extension.  Any other use of the nonce is going beyond 
the RFC's clear and explicit intentions.

To me, expanding the scope of a specification is something that is more 
appropriately done in a "next-generation" context.  That is, if you want 
to expand the scope you should increment the version number.

So if the goal is to clarify the OCSPv1 spec as it progresses up the 
standards track, the only option is to use the "MUST reject" language.

If, OTOH, the group is willing to delay OCSP's progress and put a 
revised OCSPv2 through the standards process, then expanding the scope 
is perfectly fine.

Assorted comments to several people follow:

Michael Myers wrote:
> 
> (silence WILL be taken as consent)

Mike, that statement was your first mistake!  :)

David Engberg wrote:
> 
> 
> I posit that there is a third local security policy that the MUST 
> language prohibits, and that policy can be achieved under v1 SHOULD 
> language:
> 
>   3) Send a nonce to Acme's server, and accept the response IFF
>      the response contains the nonce OR the server SECURELY signals
>      that it does not supply nonces to anyone.

This is an expansion of OCSP's scope, going beyond the spec's explicit 
statements about the use of nonces.  Support for this should be 
addressed in a v2 spec.  It's inappropriate to try to shoehorn this into v1.

David Engberg also wrote:
> 
> I disagree that we need to intentionally modify the existing RFC 
> language to absolutely prohibit implementors from allowing such optional 
> local security policies using the normal extensions mechanism in v1.

The client is perfectly free to follow the policies you propose by not 
including the nonce.  Clients gain nothing by including a nonce if 
they're willing to accept nonceless responses.

> I don't believe that anyone is condoning any insecure practices.  I 
> believe that there are several secure practices under discussion, and 
> your (legitimate) concern is that those practices were not presented 
> soon enough to be written directly into the v1 standard.  So ... leave 
> them out of the standard, but leave some room for security extensibility.

There is no need to water down the nonce extension to support the 
practices you propose.

Santosh Chokhani wrote:
> 
> When the client does not get the nonce back, it knows either there is a 
> replay or the server is doing pre-production.  But, the client has this 
> knowledge, this Update, Next Update and produced at fields, and the 
> application context to make the determination whether to reject the 
> transaction or not.

This is also an expansion, using the nonce for more than preventing 
replay attacks.  Here you're trying to use the nonce as an optimization 
-- if the nonce is in the response, the client can avoid checking those 
time fields.

Frankly, I find that optimization doesn't really gain much performance. 
  It certainly does not improve security.

If the client is willing to use the time fields to accept or reject the 
response, it has no need or reason in put a nonce in its request.

Florian Oelmaier wrote:
> 
> I object. It breaks running code in installations.

That code is not secure, and did not follow the spec.

> It changes the spirit
> of the protocol as a lot of people understood it (due to the current
> wording in RfC2560).

As I said above, it is exactly in line with the spirit of the protocol. 
  The current wording of the RFC is very clear about what the nonce is 
for.  Implementations that would "break" under Mike's proposal failed to 
read the spec properly.

> And most important, I object as there are better
> solutions already outlined (see more below).

All of the solutions you seem to favour are not in the spirit of the 
protocol, as stated in the RFC.

> Thus most clients do not know if the Responder supports nonces or not
> (e.g. due to caching). How should they, they didnt even knew the URL
> until they read the AIA!
> 
> Seeing this it is a very acceptable for a client to TRY to get a nonce,
> but to accept answers without nonces as a fallback.

No, it is not acceptable.  The RFC is very clear: use nonces to prevent 
replay attacks.  If the client is concerned about replay attacks, it 
must reject a nonceless response.

> It is a "natural"
> behaviour - I try for all extensions I support, but will fall back to
> the very basics of the standard, to the "not extended" behaviour when I
> cannot get what I want. This is the usual way of doing things in nearly
> all protocols out there, PKIX or not.

Nearly all protocols out there are insecure.  This is a security WG...

> So the very basic assumption of your argument is not true at least for
> my client. I use nonces to prevent replay attacks WHERE POSSIBLE. If it
> is not possible, I will not give up and will instead do my best to get a
> revocation information that is as good as the information in a CRL is.

This is a reasonable argument.  However, it is not what OCSPv1 was 
designed to support.  An opportunity to make clarifying changes in 
OCSPv1 as it becomes a standard is not the right time to expand its scope.

> So the very first question is:
> 
> *** IS IT REASONABLE FOR A CLIENT TO ASK FOR A NONCE BUT ALSO TO WORK
> WITH RESPONSES WITHOUT NONCE? ***

(STOP SHOUTING, please.)

> If the answer is "NO", the MUST-REJECT solution to the problem is the
> way to go. 

The answer is no.  This is clear from RFC2560's text.

		M.

--------------ms000306080004030900010605
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

--------------ms000306080004030900010605--

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 11:41:03 -0700
Importance: Normal
Sender: [email-masked]

Dave,

So how about:

1. If we can cycle v1 at Proposed (a big if); then

2. Define nonceUnsupported extension subject to
   the following semantics (I'm squeezing the
   words a bit but you'll get the drift)

3. Clients that send a nonce:

   a. MUST reject a non-nonced response
      if that response includes either the
      value "good" or "revoked" AND it fails
      to include the nonceUnsupported extension;

   b. Else, if such response includes the
      nonceUnsupported extension, clients
      MAY accept the response subject to the
      advice in the Security Considerations
      section of this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include the nonceUnsupported extension.

Note that I made no distinction between "good", "revoked" or
"unknown" in #3.b or #4.  Thus, a plain nonceless response of
"good" or "revoked" is non-conformant, while a caveated response
is subject to the client's local security policy.

Does this seem a fair compromise?  Note well it's highly
dependent on cycling v1 at Proposed.

Mike

> -----Original Message-----
> From: David Engberg [mailto:[email-masked]]
> Sent: Thursday, November 27, 2003 10:58 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> Michael Myers wrote:
> > There's a chance we maybe can if we reset 2560 back
> to Proposed,
> > still call it v1 and let it cycle there for a
> while.  I've yet
> > to hear back from Russ on that one so I've been reluctant to
> > play that card.  I think what will be the
> determining factor on
> > that potential course of action is if we can all
> agree on the
> > technical content.  The number of implementors who would be
> > affected is still quite manageable.
>
> This sounds good to me.
>
>
> > I suspect though there still will remain the core issue:
> > whether or not it is conformant in principle and in
> the spirit
> > of the RFC to send a nonceless response to a nonced
> request.  I
> > would further refine that by saying any nonceless signed
> > response containing either "good" or "revoked".  I
> could accept
> > "unknown" due to reasons of nonces not being supported as
> > indicated by a small extension to the protocol.
>
> I read the nonce description in the RFC as the client
> asking for
> something that it WANTS as opposed to demanding
> something that it NEEDS.
>   I.e. a nonce is one element in a list of things
> like nextUpdate,
> thisUpdate, producedAt, etc. that a client may use to
> decide on response
> acceptance based on the local security policy.
>
> The local policy needs to take all of these factors
> into account, and
> the absence/presence of a nonce is one factor which
> may help avoid a
> specific type of attack.  The default, recommended,
> behavior is that a
> nonceless response should be rejected unless the
> client has a darned
> good reason for accepting the response based on other
> factors (e.g. the
> response comes with a signed letter from the cert's
> issuer saying it is
> safe [safer, IMHO, but that's a separate discussion]
> to accept the
> nonceless response for its certs).
>
> It sounds like your interpretation is that the
> presence of a nonce is
> something the client NEEDS and that nonce absence
> supercedes all other
> policy considerations.  I don't think this is a
> horrible interpretation,
> but it does imply some limitations, as discussed.
>
>

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 12:34:27 -0600
Importance: Normal
Sender: [email-masked]

I think this is the best option. We definitely need a normative on how
nonces relate to pre-produced responses. Meanwhile the discussion must
go on.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 8:19 AM
> To: Florian Oelmaier; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Maybe the best thing to do is to reset 2560 back to Proposed,
> drop in a simple little extension like the below or something
> similar, put in some amply unambiguous normative language that
> makes it abundantly clear how nonces relate to pre-produced
> responses (in particular nonceless responses to nonced requests
> are strictly verboten) call it v1 still and let the RFC cycle at
> Proposed for an additional six months.  I could live with that.
> I don't know however if the IESG would let us do that.  Maybe if
> we could all agree on that course of action and ask nicely . . .
> ?
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > Florian Oelmaier
> > Sent: Wednesday, November 26, 2003 6:33 PM
> > To: 'Michael Myers'; [email-masked]
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > > I've chosen not to incorporate your well reasoned argument
> > > due to my business model.  :)
> >
> > hehehehe
> >
> > > How about in v1 we clarify by saying that "clients claiming
> > > conformance to this standard SHALL be capable of
> > rejecting . . . "
> >
> > What about something like:
> >
> > ------
> >
> > Clients including a nonce into the request MUST NOT
> > accept nonce-less
> > responses from responders that are known to be
> > capable of generating
> > nonces. If this is unknown for a certain responder,
> > clients MAY accept
> > the additional risk of accepting the nonce-less response.
> >
> > A responder MAY include the OCSPNonceSupported
> > extension into every
> > response to indicate the capability of producing
> > nonces to the client
> > (even in the case of a replay attack). The
> > OCSPNonceSupported extension
> > will be identified by the object identifier
> > id-pkix-ocsp-noncesupported,
> > while the extnValue is a boolean value indicating if
> > nonces are
> > supported by this responder (TRUE) or not (FALSE).
> >
> > id-pkix-ocsp-noncesupported     OBJECT IDENTIFIER ::=
> > { id-pkix-ocsp 8 }
> >
> > ------
> >

Date: Thu, 27 Nov 2003 12:57:43 -0500
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

Michael Myers wrote:
> There's a chance we maybe can if we reset 2560 back to Proposed,
> still call it v1 and let it cycle there for a while.  I've yet
> to hear back from Russ on that one so I've been reluctant to
> play that card.  I think what will be the determining factor on
> that potential course of action is if we can all agree on the
> technical content.  The number of implementors who would be
> affected is still quite manageable.

This sounds good to me.

> I suspect though there still will remain the core issue:
> whether or not it is conformant in principle and in the spirit
> of the RFC to send a nonceless response to a nonced request.  I
> would further refine that by saying any nonceless signed
> response containing either "good" or "revoked".  I could accept
> "unknown" due to reasons of nonces not being supported as
> indicated by a small extension to the protocol.

I read the nonce description in the RFC as the client asking for 
something that it WANTS as opposed to demanding something that it NEEDS. 
  I.e. a nonce is one element in a list of things like nextUpdate, 
thisUpdate, producedAt, etc. that a client may use to decide on response 
acceptance based on the local security policy.

The local policy needs to take all of these factors into account, and 
the absence/presence of a nonce is one factor which may help avoid a 
specific type of attack.  The default, recommended, behavior is that a 
nonceless response should be rejected unless the client has a darned 
good reason for accepting the response based on other factors (e.g. the 
response comes with a signed letter from the cert's issuer saying it is 
safe [safer, IMHO, but that's a separate discussion] to accept the 
nonceless response for its certs).

It sounds like your interpretation is that the presence of a nonce is 
something the client NEEDS and that nonce absence supercedes all other 
policy considerations.  I don't think this is a horrible interpretation, 
but it does imply some limitations, as discussed.

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 09:09:25 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B509.62D98421"

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

My opinion is still that the client should get the un-nonced response =
and then the client should throw it out.
=20
If there is a preceived need for returning a response without a nonce =
return internalError.
=20
Ryan

________________________________

From: Michael Myers [mailto:[email-masked]]
Sent: Thu 11/27/2003 9:09 AM
To: Ryan M. Hurst; Santosh Chokhani; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

The more important thing is what a caching server is required to send =
back in the event it can't respond to a nonce.
=20
Mike

	-----Original Message-----
	From: Ryan M. Hurst [mailto:[email-masked]]
	Sent: Thursday, November 27, 2003 9:48 AM
	To: Michael Myers; Santosh Chokhani; [email-masked]
	Subject: RE: DISCUSS: MUST reject in OCSPv1
=09
=09
	I don't think its silly, the client is still protected from the replay =
if the server responds to a nonced request with a un-nonced one as the =
client can decide decide if he wanted the protection or needed it.
	=20
	That may sound strange, but nonce has other implications that re-play =
protection; it also implies freshness since pre-produced responses can =
not have the right nonce in it.
	=20
	I still am not sure anything new is needed, but if it is leveraging =
criticality is probably the right way to go as long as it will not break =
folks; if it would I would fall back to the extension approach.
	=20
	Ryan
=09
	=20

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">=0A=
<HTML><HEAD><TITLE>RE: DISCUSS: MUST reject in OCSPv1</TITLE>=0A=
=0A=
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText15729 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>My opinion is =
still that the =0A=
client should get the un-nonced response and then the client should =
throw it =0A=
out.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>If there is a preceived need =
for returning =0A=
a response without a nonce return internalError.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Michael Myers =0A=
[mailto:[email-masked]]<BR><B>Sent:</B> Thu 11/27/2003 9:09 =
AM<BR><B>To:</B> =0A=
Ryan M. Hurst; Santosh Chokhani; [email-masked]<BR><B>Subject:</B> =
RE: =0A=
DISCUSS: MUST reject in OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =
size=3D2>The =0A=
more important thing is what a caching server is required to send back =
in the =0A=
event it can't respond to a nonce.</FONT></SPAN></DIV>=0A=
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =0A=
size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =0A=
size=3D2>Mike</FONT></SPAN></DIV>=0A=
<BLOCKQUOTE dir=3Dltr =0A=
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">=0A=
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma =0A=
  size=3D2>-----Original Message-----<BR><B>From:</B> Ryan M. Hurst =0A=
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, November =
27, 2003 =0A=
  9:48 AM<BR><B>To:</B> Michael Myers; Santosh Chokhani; =0A=
  [email-masked]<BR><B>Subject:</B> RE: DISCUSS: MUST reject in =0A=
  OCSPv1<BR><BR></FONT></DIV>=0A=
  <DIV id=3DidOWAReplyText19203 dir=3Dltr>=0A=
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I don't =
think its silly, =0A=
  the client is still protected from the replay if the server responds =
to a =0A=
  nonced request with a un-nonced one as the client can decide decide if =
he =0A=
  wanted the protection or needed it.</FONT></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>That may sound strange, but =
nonce has =0A=
  other implications that re-play protection; it also implies freshness =
since =0A=
  pre-produced responses can not have the right nonce in it.</FONT></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>I still am not sure =
anything new is =0A=
  needed, but if it is leveraging criticality is probably the right way =
to go as =0A=
  long as it will not break folks; if it would I would fall back to the =0A=
  extension approach.</FONT></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =0A=
size=3D2></FONT><BR>&nbsp;</DIV></BLOCKQUOTE></DIV></BODY></HTML>=0A=

------_=_NextPart_001_01C3B509.62D98421--

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

From: "Michael Myers" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 10:09:35 -0700
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C3B4CE.8F0C0C60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: DISCUSS: MUST reject in OCSPv1The more important thing is what a caching
server is required to send back in the event it can't respond to a nonce.

Mike
  -----Original Message-----
  From: Ryan M. Hurst [mailto:[email-masked]]
  Sent: Thursday, November 27, 2003 9:48 AM
  To: Michael Myers; Santosh Chokhani; [email-masked]
  Subject: RE: DISCUSS: MUST reject in OCSPv1

  I don't think its silly, the client is still protected from the replay if
the server responds to a nonced request with a un-nonced one as the client
can decide decide if he wanted the protection or needed it.

  That may sound strange, but nonce has other implications that re-play
protection; it also implies freshness since pre-produced responses can not
have the right nonce in it.

  I still am not sure anything new is needed, but if it is leveraging
criticality is probably the right way to go as long as it will not break
folks; if it would I would fall back to the extension approach.

  Ryan

------=_NextPart_000_0012_01C3B4CE.8F0C0C60
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: DISCUSS: MUST reject in OCSPv1</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
more important thing is what a caching server is required to send back =
in the=20
event it can't respond to a nonce.</FONT></SPAN></DIV>
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Mike</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ryan M. Hurst=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, November =
27, 2003=20
  9:48 AM<BR><B>To:</B> Michael Myers; Santosh Chokhani;=20
  [email-masked]<BR><B>Subject:</B> RE: DISCUSS: MUST reject in=20
  OCSPv1<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText19203 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I don't =
think its silly,=20
  the client is still protected from the replay if the server responds =
to a=20
  nonced request with a un-nonced one as the client can decide decide if =
he=20
  wanted the protection or needed it.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>That may sound strange, but =
nonce has=20
  other implications that re-play protection; it also implies freshness =
since=20
  pre-produced responses can not have the right nonce in =
it.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>I still am not sure =
anything new is=20
  needed, but if it is leveraging criticality is probably the right way =
to go as=20
  long as it will not break folks; if it would I would fall back to the=20
  extension approach.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT><BR>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0012_01C3B4CE.8F0C0C60--

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 08:48:02 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B506.A8C16179"

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

I don't think its silly, the client is still protected from the replay =
if the server responds to a nonced request with a un-nonced one as the =
client can decide decide if he wanted the protection or needed it.
=20
That may sound strange, but nonce has other implications that re-play =
protection; it also implies freshness since pre-produced responses can =
not have the right nonce in it.
=20
I still am not sure anything new is needed, but if it is leveraging =
criticality is probably the right way to go as long as it will not break =
folks; if it would I would fall back to the extension approach.
=20
Ryan

________________________________

From: [email-masked] on behalf of Michael Myers
Sent: Thu 11/27/2003 5:49 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

> -----Original Message-----
> From: Santosh Chokhani
> Sent: Wednesday, November 26, 2003 9:25 PM
> To: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Mike:
>
> Section 4.1.2 and 4.4 of the RFC 2560 support the
> position that the nonce can
> be ignored.  I can not find any statement in the RFC
> that is close to these
> two to support what you are saying.

Yes, extensions are optional.  What's missing is language along
the lines that while optional, if used must be used in the
manner indicated in the extension's definition.

Prior to the first poll, I was reviewing some list traffic on
the subject, I think it was between Florian and Ambarish.  I was
about to advise that 2560 asserts nonces must be respected but
was dismayed to learn that we hadn't done so.

Why the hard line?  Because it just seems rather silly to enable
a client to include a nonce for the purposes of anti-replay but
then leave open a loophole that allows that nonce to be ignored,
this, against all good sense of how a secure protocol should
work.  With a loophole like that, it isn't secure.  I guess we
all figured, well *of course* the nonce would be incorporated.

Mike

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>RE: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText19203 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I don't think =
its silly, the =0A=
client is still protected from the replay if the server responds to a =
nonced =0A=
request with a un-nonced one as the client can decide decide if he =
wanted the =0A=
protection or needed it.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>That may sound strange, but =
nonce has other =0A=
implications that re-play protection; it also implies freshness since =0A=
pre-produced responses can not have the right nonce in it.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I still am not sure anything =
new is needed, =0A=
but if it is leveraging criticality is probably the right way to go as =
long as =0A=
it will not break folks; if it would I would fall back to the extension =0A=
approach.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of =0A=
Michael Myers<BR><B>Sent:</B> Thu 11/27/2003 5:49 AM<BR><B>To:</B> =
Santosh =0A=
Chokhani; [email-masked]<BR><B>Subject:</B> RE: DISCUSS: MUST reject =
in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV><BR><BR><BR>=0A=
<P><FONT size=3D2>&gt; -----Original Message-----<BR>&gt; From: Santosh =0A=
Chokhani<BR>&gt; Sent: Wednesday, November 26, 2003 9:25 PM<BR>&gt; To: =0A=
[email-masked]<BR>&gt; Subject: RE: DISCUSS: MUST reject in =0A=
OCSPv1<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; Mike:<BR>&gt;<BR>&gt; Section =
4.1.2 and =0A=
4.4 of the RFC 2560 support the<BR>&gt; position that the nonce =
can<BR>&gt; be =0A=
ignored.&nbsp; I can not find any statement in the RFC<BR>&gt; that is =
close to =0A=
these<BR>&gt; two to support what you are saying.<BR><BR>Yes, extensions =
are =0A=
optional.&nbsp; What's missing is language along<BR>the lines that while =0A=
optional, if used must be used in the<BR>manner indicated in the =
extension's =0A=
definition.<BR><BR>Prior to the first poll, I was reviewing some list =
traffic =0A=
on<BR>the subject, I think it was between Florian and Ambarish.&nbsp; I =0A=
was<BR>about to advise that 2560 asserts nonces must be respected =
but<BR>was =0A=
dismayed to learn that we hadn't done so.<BR><BR>Why the hard =
line?&nbsp; =0A=
Because it just seems rather silly to enable<BR>a client to include a =
nonce for =0A=
the purposes of anti-replay but<BR>then leave open a loophole that =
allows that =0A=
nonce to be ignored,<BR>this, against all good sense of how a secure =
protocol =0A=
should<BR>work.&nbsp; With a loophole like that, it isn't secure.&nbsp; =
I guess =0A=
we<BR>all figured, well *of course* the nonce would be =0A=
incorporated.<BR><BR>Mike<BR><BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B506.A8C16179--

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

Date: Thu, 27 Nov 2003 18:16:51 +0200
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Cc: David Engberg <[email-masked]>
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

On Wed, Nov 26, 2003 at 05:19:48PM -0500, David Engberg wrote:
> ...
> Rationale:
> 
> Imagine an OCSP client who receives signed email with a cert from Acme 
> Certs.  He chains it up (e.g through bridging) to some trusted root, and 
> then finds Acme's responder URL through the cert's AIA field.  The 
> client trusts the cert, but needs to validate its revocation status 
> through OCSP.  With the "MUST" language, the client is limited to two 
> automatically-enforced local security policies:
> 
>   1) Don't send a nonce, whether or not Acme's server supports nonces.
> 
>   2) Send a nonce whether or not Acme's server supports nonces, and
>      fail to perform any validation if it does not.

Maybe announce OCSP responder capability to handle nonces
right in the AIA extension (at the same place the URL is given)?

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 08:39:47 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From:  David Engberg
> Sent: Wednesday, November 26, 2003 9:40 PM
>
> I accept your determination that we cannot specify a
> single new specific secure signalling mechanism
> (e.g. 'nonceUnsupported' extension) inside
> of the formal OCSP v1.
>

There's a chance we maybe can if we reset 2560 back to Proposed,
still call it v1 and let it cycle there for a while.  I've yet
to hear back from Russ on that one so I've been reluctant to
play that card.  I think what will be the determining factor on
that potential course of action is if we can all agree on the
technical content.  The number of implementors who would be
affected is still quite manageable.

I suspect though there still will remain the core issue:
whether or not it is conformant in principle and in the spirit
of the RFC to send a nonceless response to a nonced request.  I
would further refine that by saying any nonceless signed
response containing either "good" or "revoked".  I could accept
"unknown" due to reasons of nonces not being supported as
indicated by a small extension to the protocol.

What do you think?

Mike

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 11:09:29 -0400
Sender: [email-masked]

MIke:

I suggesetd several client side checks to Ambrish (including this one) in 
February 2002.  I was not thinking of pre-production.

As to security problem, as my e-mail denoted,the client is free to reject the 
response, use the three times as guide, or mmight know a priory that the 
Responder does pre-production and hence no nonces.

On Thu, 27 Nov 2003 06:49:06 -0700, Michael Myers wrote
> > -----Original Message-----
> > From: Santosh Chokhani
> > Sent: Wednesday, November 26, 2003 9:25 PM
> > To: [email-masked]
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > Mike:
> >
> > Section 4.1.2 and 4.4 of the RFC 2560 support the
> > position that the nonce can
> > be ignored.  I can not find any statement in the RFC
> > that is close to these
> > two to support what you are saying.
> 
> Yes, extensions are optional.  What's missing is language along
> the lines that while optional, if used must be used in the
> manner indicated in the extension's definition.
> 
> Prior to the first poll, I was reviewing some list traffic on
> the subject, I think it was between Florian and Ambarish.  I was
> about to advise that 2560 asserts nonces must be respected but
> was dismayed to learn that we hadn't done so.
> 
> Why the hard line?  Because it just seems rather silly to enable
> a client to include a nonce for the purposes of anti-replay but
> then leave open a loophole that allows that nonce to be ignored,
> this, against all good sense of how a secure protocol should
> work.  With a loophole like that, it isn't secure.  I guess we
> all figured, well *of course* the nonce would be incorporated.
> 
> Mike

Subject: remove
To: [email-masked]
From: "Marco Nicoli" <[email-masked]>
Date: Thu, 27 Nov 2003 15:47:41 +0100
Sender: [email-masked]

From: "Michael Myers" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 07:33:17 -0700
Importance: Normal
Sender: [email-masked]

I should qualify that:  nonceless "definitive" responses.  I.e.
those a containing a signed indication of either "good" or
"revoked".

Mike

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Thursday, November 27, 2003 7:19 AM
> To: Florian Oelmaier; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Maybe the best thing to do is to reset 2560 back to
> Proposed, drop in a simple little extension like the
> below or something similar, put in some amply
> unambiguous normative language that makes it
> abundantly clear how nonces relate to pre-produced
> responses (in particular nonceless responses to
> nonced requests are strictly verboten) call it v1
> still and let the RFC cycle at Proposed for an
> additional six months.  I could live with that.  I
> don't know however if the IESG would let us do that.
> Maybe if we could all agree on that course of action
> and ask nicely . . . ?
>
> Mike

From: "Michael Myers" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 07:18:45 -0700
Importance: Normal
Sender: [email-masked]

Maybe the best thing to do is to reset 2560 back to Proposed,
drop in a simple little extension like the below or something
similar, put in some amply unambiguous normative language that
makes it abundantly clear how nonces relate to pre-produced
responses (in particular nonceless responses to nonced requests
are strictly verboten) call it v1 still and let the RFC cycle at
Proposed for an additional six months.  I could live with that.
I don't know however if the IESG would let us do that.  Maybe if
we could all agree on that course of action and ask nicely . . .
?

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Florian Oelmaier
> Sent: Wednesday, November 26, 2003 6:33 PM
> To: 'Michael Myers'; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> > I've chosen not to incorporate your well reasoned argument
> > due to my business model.  :)
>
> hehehehe
>
> > How about in v1 we clarify by saying that "clients claiming
> > conformance to this standard SHALL be capable of
> rejecting . . . "
>
> What about something like:
>
> ------
>
> Clients including a nonce into the request MUST NOT
> accept nonce-less
> responses from responders that are known to be
> capable of generating
> nonces. If this is unknown for a certain responder,
> clients MAY accept
> the additional risk of accepting the nonce-less response.
>
> A responder MAY include the OCSPNonceSupported
> extension into every
> response to indicate the capability of producing
> nonces to the client
> (even in the case of a replay attack). The
> OCSPNonceSupported extension
> will be identified by the object identifier
> id-pkix-ocsp-noncesupported,
> while the extnValue is a boolean value indicating if
> nonces are
> supported by this responder (TRUE) or not (FALSE).
>
> id-pkix-ocsp-noncesupported     OBJECT IDENTIFIER ::=
> { id-pkix-ocsp 8 }
>
> ------
>

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Straw poll: An advice to a commercial CA
Date: Thu, 27 Nov 2003 15:02:56 +0100
Sender: [email-masked]

>If cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"? 

Oh Peter, now you become far too practical for _this_ list!

But it is indeed a real challenge to write a GUI to be used by
ordinary IS administrators, for a mechanism that you need a Phd
or better to grasp!

I guess you can wait with the GUI as long as Microsoft will
wait with a GUI in their products.  That is, forever.

Eureka, I got it!  Since this is black magic anyway, Microsoft
could make this configurable with Regedit!  That's how MSFT
usually treat stuff that you really shouldn't muck around with
at all or only on your own risk.  Finally RFC3280 has found
its true sole-mate.  It was a long journey...

Anders

From: "Michael Myers" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 06:49:06 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Santosh Chokhani
> Sent: Wednesday, November 26, 2003 9:25 PM
> To: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Mike:
>
> Section 4.1.2 and 4.4 of the RFC 2560 support the
> position that the nonce can
> be ignored.  I can not find any statement in the RFC
> that is close to these
> two to support what you are saying.

Yes, extensions are optional.  What's missing is language along
the lines that while optional, if used must be used in the
manner indicated in the extension's definition.

Prior to the first poll, I was reviewing some list traffic on
the subject, I think it was between Florian and Ambarish.  I was
about to advise that 2560 asserts nonces must be respected but
was dismayed to learn that we hadn't done so.

Why the hard line?  Because it just seems rather silly to enable
a client to include a nonce for the purposes of anti-replay but
then leave open a loophole that allows that nonce to be ignored,
this, against all good sense of how a secure protocol should
work.  With a loophole like that, it isn't secure.  I guess we
all figured, well *of course* the nonce would be incorporated.

Mike

From: "Anders Rundgren" <[email-masked]>
To: "Joseph Doekbrijder" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Straw poll: An advice to a commercial CA
Date: Thu, 27 Nov 2003 13:01:12 +0100
Sender: [email-masked]

Doesn't your scheme make an RP trusting the "expensive" CA
also trust the "cheap" CA as they share a common root?

And there could also be just two different "expensive" issuances
that are incompatible like server-side SSL certs and certs for
individuals.

It looks to me that you move potential problems to the RP SW.
Mathematically OK? For sure.  Standards-compliant?  For sure.
But working?  Under strictly monitored conditions only.  Such
conditions are unlikely to be met when you start to count RPs
in the thousands and up.

Anyway. several other folks on the list seem to agree that
such schemes (including policy OID-enhanced path validation)
only work in "managed" or "community" based PKIs.

In my opinion the need for standards is much more evident
in "unmanaged" spaces.

Anders

----- Original Message -----
From: "Joseph Doekbrijder" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 27, 2003 10:43
Subject: Re: Straw poll: An advice to a commercial CA

Only logical thing to do is a single root, signing the cheap CA which in
its turn signs the expensive CA.
Mathematically correct, includes trust logic, liability levels etc, etc...

This is how we do it. :-)

Cheers

Josh

Anders Rundgren wrote:

>Well,
>Since the list is close to "vibrant" with emotions, why not
>put RFC3280 through the litmus test?
>
>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots
>
>Lets rock!
>
>
>
--
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
L�wenstrasse 1, CH-8001 Z�rich
Tel: +41 43 344 88 11 Mobil: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

Date: Fri, 28 Nov 2003 00:33:35 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Peter.

Date: Fri, 28 Nov 2003 00:27:25 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Straw poll: An advice to a commercial CA
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Anders Rundgren <[email-masked]> writes:

>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots

I'm going to have to qualify my answer by saying that it'd differ whether I
was acting for the CA or the RP, and whether it's an open or closed
environment.  If it's a closed environment I'd let them do whatever they feel
like and whatever the software supports (that is, find out what their software
will let them do, get them to test it to make sure it really does what the
vendor claims it does, go a few rounds with the vendor to make it actually do
what they claim, and then let them go with what they're comfortable with).
Since they don't have the option of changing the software, they'll have to do
what they can with what they've got.

If it's an open environment then given the almost complete lack of support for
policy restrictions and management (as Anders has pointed out), I'd tell them
to go for multiple CAs and handle it via the trusted-roots mechanism, which
pretty much everything supports.  Oh, and I'd probably have to sit through
interminable discussions with lawyers about how to word the CPS so that they
can do whatever they want to the RP without assuming any liability.

To answer an earlier question about support for policy restrictions, cryptlib
supports these (policy constraints with all its weird variations).  If
cryptlib finds constraints in a CA cert it'll apply them down the chain, but
there's no way for a user to configure the behaviour.  The reason for this is
that no-one has ever asked for this [0], so I can't even begin to imagine what
sort of interface it'd require to manage things.  Do users type in a list of
OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
policies advertised by this CA"?  Can you apply different policies to
different sets of certs?  Do you require the user to have read the policy (via
the URL) via a click-through mechanism before they enable its use?  What if
someone runs a MITM on them when they do this?  (It's most amusing that the
logotype draft has hashes to stop someone changing the inconsequential logo
that they see next to the cert, but there's nothing to prevent someone being
sent a completely bogus legal agreement when they ask for the policy).  If the
cert happens to use HTTPS for the policy (I've seen one or two that do), what
policy do you use for the cert securing the HTTPS transfer?  What happens if
the CA asserts anyPolicy but has a URL pointing to a very specific policy that
isn't anyPolicy?  What about qualifiers, do users have to agree to all of
those as well?  What are the policies applied for qualifiers, given that
there's only a single policy URL present?  Do you have to apply qualifiers
when applying policy constraints?  If not, why are they there?  etc etc etc.

Once all that is clearly defined somewhere, I can add support for it to my
code.  Until then, the policy extension serves best as a legal defence
mechanism for the CA to protect themselves from RPs, as per the legal analysis
I posted a day or two back.

Peter.

[0] Since cryptlib is open-source, it's quite possible that users have made
    custom mods to it to handle this, but I wouldn't hear about it unless they
    have problems.  I know that there are quite a number of customised
    versions in use in Europe to handle national signature law/regulation
    quirks (the fact that no government can resist adding its own incompatible
    changes to the legislation is a great help for OSS PKI software, because
    no commercial vendor can support it out-of-the-box), but no-ones ever come
    to me with questions about policy constraints.

Date: Thu, 27 Nov 2003 12:07:02 +0200
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Cc: Michael Myers <[email-masked]>
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

On Wed, Nov 26, 2003 at 05:24:45PM -0700, Michael Myers wrote:
...
> I should note as well that another of this WG's products, SCVP,
> very clearly respects the underlying principle.  c.f. Section
> 3.4 of
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
> where it is stated that:
> 
>     "If the client includes a requestNonce value
>     in the request, then the server MUST return the
>     same value in the response."
> 
> So again, it's not like this WG is blind the principle.

Please let me second that protocol designers generally have
quite good understanding of security. Another example might be
nonces in SET specifications.

Book 2, page 67:
SET defines ... "nonces" ... to defeat "playback attack".
The sending entity shall generate a random value and insert this value
into the message. The recipient of the message shall copy this value
into the corresponding response message.

Please also note "shall" wording in SET is actually a quite strong one.
Book 2, page 313 (Cardholder processing PInitRes generated by Merchant):
5. Verify Chall-C against the Chall-C in the transaction record.
If Chall-Cs different:
a) Return an Error message with ErrorCode set to challengeMismatch
b) Stop processing PInitRes

Please note there is no option to ask Cardholder whether it is "Ok"
to accept a response from Merchant without a nonce (Cardholder's Challenge).

..yes, I know, SET is not widely used yet. I believe nonce handling
is not the reason

regards,
Vadim

Date: Thu, 27 Nov 2003 10:53:06 +0100
From: Joseph Doekbrijder <[email-masked]>
Organization: SwissSign AG
To: Hans Nilsson <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070402000705070609050203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I know of another: SwissSign
Here too the features are used by customers to define levels of 
certificates with respect to the registration processes and liability...

Cheers

Josh  

Hans Nilsson wrote:

>I know of at least one CA product (SmartTrust Certificate Manager) which can
>supports multiple issuance of certs (with different CPs) per CA root.
>
>I know that this feature also is used by several of SmartTrust's customers,
>for example for distinguishing between different issuing procedures and/or
>private key storage media.
>
>And when talking about Relying Party software, we do not usually mean
>Outlook Express. After all, secure e-mail is not the number 1 PKI
>application. 
>Instead, RPs are usually servers, validating signatures in e-government and
>e-banking applications. And RP software (from MS and others) can pick out
>any field of a certificate and make a decision based on that.
>
>Hans
>
>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>    
>>
>On
>  
>
>>Behalf Of Anders Rundgren
>>Sent: Wednesday, November 26, 2003 2:30 PM
>>To: [email-masked]
>>Subject: Re: Certificate Policy Standardization
>>
>>
>>Hum,
>>
>>I wonder how many times I have to repeat the same very basic
>>questions and only getting answers back in "ASN.1"?  Sort of.
>>So here we go again...
>>
>>Because they have understood the problems associated?
>>Because they enjoy "violating" standards?
>>Because they are ignorant?
>>Because their budget is too limited?
>>Other?
>>
>>Anders
>>
>>----- Original Message -----
>>From: "Santosh Chokhani" <[email-masked]>
>>To: <[email-masked]>
>>Sent: Wednesday, November 26, 2003 12:04
>>Subject: RE: Certificate Policy Standardization
>>
>>
>>
>>Anders:
>>
>>The relying parties are free to ignore the policies and policy related
>>extensions altogether and verify paths.  The certification path will
>>    
>>
>verify
>  
>
>>unless:
>>
>>1.  One or more CAs in the path require that the certification path be
>>    
>>
>valid
>  
>
>>for a policy; or
>>
>>2.  Make the policy related extensions critical.
>>
>>While some may view the two conditions as interoperability problem, I view
>>it CA(s) saying that I do not want you to use the certificate unless you
>>understand and abide by constraints I impose on the certificates.
>>
>>The current X.509 and RFC 3280 permit you build PKI and applications that
>>    
>>
>do
>  
>
>>not use certificate policies.  So, I do not quite understand your concern
>>below.
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>    
>>
>On
>  
>
>>Behalf Of Anders Rundgren
>>Sent: Wednesday, November 26, 2003 4:03 AM
>>To: Santosh Chokhani; [email-masked]
>>Subject: Re: Certificate Policy Standardization
>>
>>
>>
>>
>>    
>>
>>>I am not what you mean by ".....another useless PKIX bloat extension".
>>>      
>>>
>>>If properly used by the CA and relying party systems, the certificate
>>>policy OID can be used to provide amount of trust the relying party
>>>should place in a certificate.
>>>      
>>>
>>What Michael referred to as "bloat" is not policy identifiers themselves
>>    
>>
>but
>  
>
>>that they need another trust adminstration GUI and associated hassles.
>>
>>Policy identifiers used for path validation purposes is indeed a very
>>"fancy" thing from a technical point of view (maybe 2% of the people
>>subscribed to the PKIX list can understand this part of RFC3280...), but
>>from an interoperability point of view they are not that great.
>>
>>Hum, there simply must be a reason why practically all commercial CAs have
>>selected an entirely different approach.  And that they did this
>>    
>>
>completely
>  
>
>>on their own without any commitee descision etc.
>>
>>I wonder how this really happend.   Could it be...
>>
>>    that it sort of feels "natural"?
>>
>>/a
>>
>>    
>>
>
>
>
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
L�wenstrasse 1, CH-8001 Z�rich
Tel: +41 43 344 88 11 Mobil: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

--------------ms070402000705070609050203
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

--------------ms070402000705070609050203--

Date: Thu, 27 Nov 2003 10:43:22 +0100
From: Joseph Doekbrijder <[email-masked]>
Organization: SwissSign AG
To: Anders Rundgren <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Straw poll: An advice to a commercial CA
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030705020108080008040402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Only logical thing to do is a single root, signing the cheap CA which in 
its turn signs the expensive CA.
Mathematically correct, includes trust logic, liability levels etc, etc...

This is how we do it. :-)

Cheers

Josh

Anders Rundgren wrote:

>Well,
>Since the list is close to "vibrant" with emotions, why not
>put RFC3280 through the litmus test?
>
>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots
>
>Lets rock!
>
>  
>
-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
L�wenstrasse 1, CH-8001 Z�rich
Tel: +41 43 344 88 11 Mobil: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

--------------ms030705020108080008040402
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

--------------ms030705020108080008040402--

Date: Wed, 26 Nov 2003 23:40:26 -0500
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

I accept your determination that we cannot specify a single new specific 
secure signalling mechanism (e.g. 'nonceUnsupported' extension) inside 
of the formal OCSP v1.

I disagree that we need to intentionally modify the existing RFC 
language to absolutely prohibit implementors from allowing such optional 
local security policies using the normal extensions mechanism in v1. 
I.e. make the language "SHOULD" to unambiguously convey your intent for 
best practices, but leave room for people to knowingly extend under v1 
when the server, client, and local security administrators all have 
security needs that go past your original design.

I don't believe that anyone is condoning any insecure practices.  I 
believe that there are several secure practices under discussion, and 
your (legitimate) concern is that those practices were not presented 
soon enough to be written directly into the v1 standard.  So ... leave 
them out of the standard, but leave some room for security extensibility.

Thanks

Michael Myers wrote:
> Dave,
> 
> As I hope you realize, I take your point in a v2 context.
> However, in v1, there was no discussion whatsoever regarding
> conditional incorporation of a client's nonce.  This is a new
> requirement, leading to new processing functionality and
> doubtless must be taken up in v2 on that basis.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 00:25:08 -0400
Sender: [email-masked]

Mike:

Section 4.1.2 and 4.4 of the RFC 2560 support the position that the nonce can 
be ignored.  I can not find any statement in the RFC that is close to these 
two to support what you are saying.

I do not understand such a hard position being take on the nonce matter when 
RFC itself lacks that much support for it.

When the client does not get the nonce back, it knows either there is a 
replay or the server is doing pre-production.  But, the client has this 
knowledge, this Update, Next Update and produced at fields, and the 
application context to make the determination whether to reject the 
transaction or not.

Decision insist on rekection is purely arbitarary.

On Wed, 26 Nov 2003 17:24:45 -0700, Michael Myers wrote
> Dave,
> 
> As I hope you realize, I take your point in a v2 context.
> However, in v1, there was no discussion whatsoever regarding
> conditional incorporation of a client's nonce.  This is a new
> requirement, leading to new processing functionality and
> doubtless must be taken up in v2 on that basis.
> 
> Meanwhile I remained disturbed that this WG of the IETF Security
> Area will walk away from this issue tacitly condoning an
> insecure practice by inaction on "MUST reject".  It's a tough
> call, I know, but one that is supported by prior poll and an
> issue that begs clarification before this insecure practice
> finds it way to even more environments.  At least, that's my
> opinion.
> 
> I should note as well that another of this WG's products, SCVP,
> very clearly respects the underlying principle.  c.f. Section
> 3.4 of
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
> where it is stated that:
> 
>     "If the client includes a requestNonce value
>     in the request, then the server MUST return the
>     same value in the response."
> 
> So again, it's not like this WG is blind the principle.
> 
> If "MUST reject" in v1 causes such pain, then find alternative
> means to signal to the relying party that their use of nonces is
> not acceptable and thus motivate a retry.  Goodness knows, web
> surfers today receive ample notice that cookies must be enabled
> to participate on many sites.
> 
> Mike
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > David Engberg
> > Sent: Wednesday, November 26, 2003 3:20 PM
> > To: [email-masked]
> > Subject: Re: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> >
> > In brief:  I would object to a plan to require that
> > v1-compatible
> > clients MUST reject nonceless responses for nonced
> > requests, regardless
> > of local security policy.  I would favor a plan to
> > strongly recommend
> > that v1-compatible clients SHOULD reject nonceless
> > responses for nonced
> > requests.
> >
> > Rationale:
> >
> > Imagine an OCSP client who receives signed email with
> > a cert from Acme
> > Certs.  He chains it up (e.g through bridging) to
> > some trusted root, and
> > then finds Acme's responder URL through the cert's
> > AIA field.  The
> > client trusts the cert, but needs to validate its
> > revocation status
> > through OCSP.  With the "MUST" language, the client
> > is limited to two
> > automatically-enforced local security policies:
> >
> >    1) Don't send a nonce, whether or not Acme's
> > server supports nonces.
> >
> >    2) Send a nonce whether or not Acme's server
> > supports nonces, and
> >       fail to perform any validation if it does not.
> >
> > These two local security policies are both perfectly
> > valid for many
> > users, but the indirect question being asked is:  Are
> > these the ONLY two
> > security policies that v1 OCSP clients may permit
> > users to choose.
> >
> > I posit that there is a third local security policy
> > that the MUST
> > language prohibits, and that policy can be achieved
> > under v1 SHOULD
> > language:
> >
> >    3) Send a nonce to Acme's server, and accept the
> > response IFF
> >       the response contains the nonce OR the server
> > SECURELY signals
> >       that it does not supply nonces to anyone.
> >
> > There was plenty of discussion around the best way to
> > achieve this
> > secure signalling, but there was overwhelming
> > consensus on this list
> > that this should at least be a theoretical option.
> > By using SHOULD, you
> > permit willing clients and servers to extend RFC2560
> > (that's what
> > extensions are there for?) to adopt such an optional
> > security model,
> > rather than arbitrarily preventing all such extensibility.
> >
> > No one is arguing that this third local security
> > policy must be
> > implemented by every client and server, but by
> > adopting language using
> > SHOULD instead of MUST, you will permit v1-compliant
> > servers and clients
> > to at least consider implementing such a policy
> > before v2-final in a few
> > years.
> >
> >
> >

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 02:33:26 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> I've chosen not to incorporate your well reasoned argument 
> due to my business model.  :)

hehehehe

> How about in v1 we clarify by saying that "clients claiming 
> conformance to this standard SHALL be capable of rejecting . . . "

What about something like: 

------

Clients including a nonce into the request MUST NOT accept nonce-less
responses from responders that are known to be capable of generating
nonces. If this is unknown for a certain responder, clients MAY accept
the additional risk of accepting the nonce-less response. 

A responder MAY include the OCSPNonceSupported extension into every
response to indicate the capability of producing nonces to the client
(even in the case of a replay attack). The OCSPNonceSupported extension
will be identified by the object identifier id-pkix-ocsp-noncesupported,
while the extnValue is a boolean value indicating if nonces are
supported by this responder (TRUE) or not (FALSE).

id-pkix-ocsp-noncesupported     OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }

------

From: "Michael Myers" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 17:44:04 -0700
Importance: Normal
Sender: [email-masked]

Florian,

I've chosen not to incorporate your well reasoned argument due
to my business model.  :)

More seriously, if we can't agree on "MUST reject" clarification
language in v1, could we possibly agree on some other language
that causes v1 implementors to at least stop and consider the
implications of their actions?  v2 is by no means a foregone
conclusion and meanwhile v1 is just now gaining appreciable
traction.

How about in v1 we clarify by saying that "clients claiming
conformance to this standard SHALL be capable of rejecting . . .
"

Mike

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 17:24:45 -0700
Importance: Normal
Sender: [email-masked]

Dave,

As I hope you realize, I take your point in a v2 context.
However, in v1, there was no discussion whatsoever regarding
conditional incorporation of a client's nonce.  This is a new
requirement, leading to new processing functionality and
doubtless must be taken up in v2 on that basis.

Meanwhile I remained disturbed that this WG of the IETF Security
Area will walk away from this issue tacitly condoning an
insecure practice by inaction on "MUST reject".  It's a tough
call, I know, but one that is supported by prior poll and an
issue that begs clarification before this insecure practice
finds it way to even more environments.  At least, that's my
opinion.

I should note as well that another of this WG's products, SCVP,
very clearly respects the underlying principle.  c.f. Section
3.4 of
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
where it is stated that:

    "If the client includes a requestNonce value
    in the request, then the server MUST return the
    same value in the response."

So again, it's not like this WG is blind the principle.

If "MUST reject" in v1 causes such pain, then find alternative
means to signal to the relying party that their use of nonces is
not acceptable and thus motivate a retry.  Goodness knows, web
surfers today receive ample notice that cookies must be enabled
to participate on many sites.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Wednesday, November 26, 2003 3:20 PM
> To: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> In brief:  I would object to a plan to require that
> v1-compatible
> clients MUST reject nonceless responses for nonced
> requests, regardless
> of local security policy.  I would favor a plan to
> strongly recommend
> that v1-compatible clients SHOULD reject nonceless
> responses for nonced
> requests.
>
> Rationale:
>
> Imagine an OCSP client who receives signed email with
> a cert from Acme
> Certs.  He chains it up (e.g through bridging) to
> some trusted root, and
> then finds Acme's responder URL through the cert's
> AIA field.  The
> client trusts the cert, but needs to validate its
> revocation status
> through OCSP.  With the "MUST" language, the client
> is limited to two
> automatically-enforced local security policies:
>
>    1) Don't send a nonce, whether or not Acme's
> server supports nonces.
>
>    2) Send a nonce whether or not Acme's server
> supports nonces, and
>       fail to perform any validation if it does not.
>
> These two local security policies are both perfectly
> valid for many
> users, but the indirect question being asked is:  Are
> these the ONLY two
> security policies that v1 OCSP clients may permit
> users to choose.
>
> I posit that there is a third local security policy
> that the MUST
> language prohibits, and that policy can be achieved
> under v1 SHOULD
> language:
>
>    3) Send a nonce to Acme's server, and accept the
> response IFF
>       the response contains the nonce OR the server
> SECURELY signals
>       that it does not supply nonces to anyone.
>
> There was plenty of discussion around the best way to
> achieve this
> secure signalling, but there was overwhelming
> consensus on this list
> that this should at least be a theoretical option.
> By using SHOULD, you
> permit willing clients and servers to extend RFC2560
> (that's what
> extensions are there for?) to adopt such an optional
> security model,
> rather than arbitrarily preventing all such extensibility.
>
> No one is arguing that this third local security
> policy must be
> implemented by every client and server, but by
> adopting language using
> SHOULD instead of MUST, you will permit v1-compliant
> servers and clients
> to at least consider implementing such a policy
> before v2-final in a few
> years.
>
>
>

From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Carlisle Adams'" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 00:54:09 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

#### Summary, detailed response below ####

I would propose the following process to solve this discussion:

+Find an answer to the question "IS IT REASONABLE FOR A CLIENT 
|  TO ASK FOR A NONCE BUT ALSO TO WORK WITH RESPONSES WITHOUT 
|  NONCE?". 
|
+--- If the answer is "NO": 
|        choose the "MUST-REJECT" proposal. 
|
+--+ If the answer is "YES":
   |
   +--+ choose one of the proposed methods answering the 
   |       questions "HOW CAN THE CLIENT TELL THE RESPONDER, 
   |       HOW IT INTENDS TO HANDLE NONCE-LESS RESPONSES?" 
   |         (proposed methods: critical flag for nonces,
   |          will-accept-nonceless-response extension)
   |
   +--+ choose one of the proposed methods answering the 
           questions "HOW CAN THE CLIENT TELL THE RESPONDER, 
           HOW IT INTENDS TO HANDLE NONCE-LESS RESPONSES?"
             (proposed methods: NonceSupported extension,
              NonceUnsupported extension, server-generated nonces)

#### Detailed response, LONG!!! ####

> 1.  Regarding v1, clarify per the minutes as
>     2560 goes from Proposed to Draft.  The
>     operative text of which is that clients
>     MUST reject a response that fails to
>     incorporate a client's nonce.

I object. It breaks running code in installations. It changes the spirit
of the protocol as a lot of people understood it (due to the current
wording in RfC2560). And most important, I object as there are better
solutions already outlined (see more below).

> To initiate the v1 discussion, my opinions are as follows.
> 
> 1.  Nonces were established in OCSP to enable
>     client driven prevention of replay attacks.
>     Failure to respect a client's nonce is a
>     direct denial of a client's request for
>     this security service.  A responder that
>     does so is contributing to the very security
>     risks the requestor is seeking to mitigate.

The whole AIA system of RfC2560 and 3280 indicates that clients do not
have any knowledge of the remote OCSP-Responder (otherwise there would
be no need to indicate the URL of the responder in the certificate).
Thus most clients do not know if the Responder supports nonces or not
(e.g. due to caching). How should they, they didnt even knew the URL
until they read the AIA!

Seeing this it is a very acceptable for a client to TRY to get a nonce,
but to accept answers without nonces as a fallback. It is a "natural"
behaviour - I try for all extensions I support, but will fall back to
the very basics of the standard, to the "not extended" behaviour when I
cannot get what I want. This is the usual way of doing things in nearly
all protocols out there, PKIX or not.

So the very basic assumption of your argument is not true at least for
my client. I use nonces to prevent replay attacks WHERE POSSIBLE. If it
is not possible, I will not give up and will instead do my best to get a
revocation information that is as good as the information in a CRL is.

So the very first question is:

*** IS IT REASONABLE FOR A CLIENT TO ASK FOR A NONCE BUT ALSO TO WORK
WITH RESPONSES WITHOUT NONCE? ***

If the answer is "NO", the MUST-REJECT solution to the problem is the
way to go. 

If the answer is "YES", the MUST-REJECT solution is not a good way to
go. As outlined above, I think this IS reasonable and there are other
implementors out there thinking that, too. So if the answer is "YES" we
have to answer two additional questions:

The first question is:

*** HOW CAN THE CLIENT TELL THE RESPONDER, HOW IT INTENDS TO HANDLE
NONCE-LESS RESPONSES? ***

Proposals on the table:
- critical-Flag for nonces
- new request extensions

Due to security reasons (an attacker could replay nonce-less responses
from a responder usually supporting nonces) we have a second question to
answer:

*** HOW CAN THE CLIENT TELL THE RESPONDER, HOW IT INTENDS TO HANDLE
NONCE-LESS RESPONSES? ***

Proposals on the table:
- NonceSupported extension
- NonceUnsupported extension
- server generated nonces

So the process forward in my eyes is really simple:
Find an answer to the question "IS IT REASONABLE FOR A CLIENT TO ASK FOR
A NONCE BUT ALSO TO WORK WITH RESPONSES WITHOUT NONCE?". 

If the answer is "NO", choose the "MUST-REJECT" proposal. 

If the answer is "YES", choose one of the proposed methods answering the
questions "HOW CAN THE CLIENT TELL THE RESPONDER, HOW IT INTENDS TO
HANDLE NONCE-LESS RESPONSES?" and "HOW CAN THE CLIENT TELL THE
RESPONDER, HOW IT INTENDS TO HANDLE NONCE-LESS RESPONSES?".

> 2.  While 2560 also enables use of pre-produced
>     responses, nonces and pre-produced responses
>     are by definition mutually exclusive.  This
>     effect should be immediately obvious to even
>     the most naive of implementors, else they have
>     no business writing code against this standard.
>     A competent level of technical proficiency
>     in implementing secure protocols is assumed.

That is correct. A responder will either support nonces or caching. But
that is not the point, because the client DOES NOT KNOW which way the
responder is working.

> 3.  The "breakage" poll indicates that an
>     overwhelming majority of OCSP implementors
>     possess this competency.  11 of 12 client-side
>     implementors reported no breakage with
>     "MUST reject" while 10 of 12 server-side
>     implementors responded likewise.

I will not discuss the breakage poll. It is long superseded by the
discussion. The poll should be: "Does this proposal break installations
or valid use-cases of your software?" 

> 4.  The two server-side breakage points occur
>     as a consequence of their use of pre-produced
>     responses in a context where they have no
>     administrative control over clients' use of
>     nonces.  This can be addressed in v2, but in
>     a v1 context we have no choice but to clarify
>     original intent as ratified by the breakage poll.
>     This breakage could also be relieved by relay
>     of OCSP requests.

We all know we could go that way. But why should we do it? There are
alternate proposals. There are better ways of doing it. Multiple people
pointed out other solutions outwitting this proposal in every aspect. I
agree with you, technically the proposal is possible, but we can do it
another way round without the ugly downsides.

---- for the interested readers, no new arguments behind this line ----

> 5.  The absence of normative language providing a
>     tutorial on the proper use of nonces in a
>     security protocol SHOULD NOT be taken up by
>     any participant in this WG as an excuse to
>     refute sound security principles.  Active
>     participants in the Security Area of the IETF
>     should be able to assume of their peers a
>     superior grasp of and respect for foundational
>     principles.

[A rant?] I agree. I also think that active participants of this WG and
security experts in general should be open-minded, self-critical and
intelligent. I am sure that all people in this WG cultivate these
virtues. And I am sure that you do not intend to indicate that people
objecting to your arguments to not have a grasp and respect for
foundational principles.

> Objections to the "MUST reject" clarification are sought on 
> the basis of sound security engineering principles rather 
> than artful readings of ancillary language that enable 
> specious excuse from adherence to these principles in order 
> to justify current business models.

/agree

But mind: While I dont care for business-models, I care for use-cases.
There is no need to define a standard that is not able to serve the
use-cases needed. So we have to care about reasonable use-cases. If we
dont do that, we should advise people not to use any internet based
communications in security critical environments, as this is the most
secure option. 

> We are setting standards that must survive the test of time.  
> We are supposed to check our corporate identities at the 
> door.  We are supposed to be individual engineers chartered 
> to improve Internet security.  Let us do so and get this 
> problem solved.

/agree

> My thanks to you all in advance for your patience with the 
> length of this note.

I am very glad that you bring this discussion on again. We cannot let
the Certificate Policy OID discussion get more attention as the OCSP
nonce discussion :) /cheer

-- 
Florian Oelmaier
SyTrust

Date: Thu, 27 Nov 2003 00:43:13 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Straw poll: An advice to a commercial CA
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <006601c3b44f$66f98330$0500a8c0@arport> on Wed, 26 Nov 2003 19:59:20 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Since the list is close to "vibrant" with emotions,
anders.rundgren> why not put RFC3280 through the litmus test?
anders.rundgren> 
anders.rundgren> Assume that you as PKI professionals would advice a
anders.rundgren> commercial TTP CA on how to configure their issuance
anders.rundgren> for the following: 
anders.rundgren> 1. Free e-mail roundtrip-verification certficates.
anders.rundgren>    Low insurance level
anders.rundgren> 2. Expensive (high insurance level) multi-usage
anders.rundgren>    certificates for individuals using strong
anders.rundgren>    verification procedures.
anders.rundgren> 
anders.rundgren> Note: the service is to be launched ASAP and has the
anders.rundgren> only objective, making money by serving its
anders.rundgren> subscribers well.
anders.rundgren> 
anders.rundgren> Indicate your advice by the word in uppercase.
anders.rundgren> 
anders.rundgren> SINGLE: A single root + possibly some CP OIDs to
anders.rundgren>         spice things up 
anders.rundgren> MULTIPLE: Different roots

Well, it depends on several factors:

 - What's your value for "ASAP"?  Yesterday?  Immediately?  In a
   month?  Within half a year?
 - What does "serving it's subscribers well" mean?

I think I'd go single root with a set of policy OIDs if possible.  I'm
assuming that with current implementations, it wouldn't be too
difficult to set upp a hierarchical PKI that allows such constructs
and have the client software do verification properly, except for the
check on policy OIDs.  Policy OID checking would probably require quite
a bit of hacking for some time.

Note that except for the email-only certificates, the client
certificates are of value to the servers, mostly.  It wouldn't be too
difficult to deploy some kind of gateway that does policy checking
before letting users go on to the stuff they are authorized to view or
handle.  And with time, I'm assuming the servers serving "the stuff"
could handle such things on their own.

Anyhow, I'm a bit tired, so if the above doesn't make sense, I'll
blame it on that and get back tomorrow...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "L Williams" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Straw poll: An advice to a commercial CA
Date: Wed, 26 Nov 2003 15:41:57 -0800
Importance: Normal
Sender: [email-masked]

I'll bite. First, I disagree with your framing of the question. What you
seem to be implying is that you have requirements that dictate two very
different vetting processes. You are essentially saying that the differences
in the vetting process translate to two completely different levels of
trust, and you want a way to communicate that to relying parties. I'm
pointing this out because the use of "e-mail roundtrip verification" in your
statement below is irrelevant.

With that setup, the most practical solution is to use 2 different root CAs.
The reason is that a large number of existing applications (and protocols)
lack support for differentiating between policy OIDs. For example, the TLS
protocol gives you a list of trusted issuers, not trusted issuers and CP
OIDs. I'm not aware of an email client that can differentiate certificate
level based on CP OID.

With that said, it would be a non sequitur to assume that this means that CP
OIDs are irrelevant. They lack practical applicability for this particular
use. They are quite useful in controlled/managed environments, such as large
corporate environments.

Your much bigger problem is going to be determining a way to effectively
signal to the relying parties what types of uses you intended the issued
certificate to be used for. I would consider that to be much more
contentious and problematic than deciding if I need one root or two.

-Laudon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: Wednesday, November 26, 2003 10:59 AM
To: Stephen Kent
Cc: [email-masked]
Subject: Straw poll: An advice to a commercial CA

Well,
Since the list is close to "vibrant" with emotions, why not
put RFC3280 through the litmus test?

Assume that you as PKI professionals would advice a commercial
TTP CA on how to configure their issuance for the following:
1. Free e-mail roundtrip-verification certficates.  Low insurance level
2. Expensive (high insurance level) multi-usage certificates for individuals
using strong verification procedures.

Note: the service is to be launched ASAP and has the only
objective, making money by serving its subscribers well.

Indicate your advice by the word in uppercase.

SINGLE: A single root + possibly some CP OIDs to spice things up
MULTIPLE: Different roots

Lets rock!

/a

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 26, 2003 15:55
Subject: Re: Certificate Policy Standardization

At 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  >I am not what you mean by ".....another useless PKIX bloat extension".
>
>>If properly used by the CA and relying party systems, the certificate
policy
>>OID can be used to provide amount of trust the relying party should place
in
>>a certificate.
>
>What Michael referred to as "bloat" is not policy identifiers themselves
>but that they need another trust adminstration GUI and associated hassles.
>
>Policy identifiers used for path validation purposes is indeed a
>very "fancy" thing from a technical point of view (maybe 2% of the
>people subscribed to the PKIX list can understand this part of
>RFC3280...), but from an interoperability point of view they are
>not that great.
>
>Hum, there simply must be a reason why practically all commercial
>CAs have selected an entirely different approach.  And that they did
>this completely on their own without any commitee descision etc.
>
>I wonder how this really happend.   Could it be...
>
>     that it sort of feels "natural"?
>
>/a

could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...

Steve

Date: Wed, 26 Nov 2003 17:19:48 -0500
From: David Engberg <[email-masked]>
To: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

In brief:  I would object to a plan to require that v1-compatible 
clients MUST reject nonceless responses for nonced requests, regardless 
of local security policy.  I would favor a plan to strongly recommend 
that v1-compatible clients SHOULD reject nonceless responses for nonced 
requests.

Rationale:

Imagine an OCSP client who receives signed email with a cert from Acme 
Certs.  He chains it up (e.g through bridging) to some trusted root, and 
then finds Acme's responder URL through the cert's AIA field.  The 
client trusts the cert, but needs to validate its revocation status 
through OCSP.  With the "MUST" language, the client is limited to two 
automatically-enforced local security policies:

   1) Don't send a nonce, whether or not Acme's server supports nonces.

   2) Send a nonce whether or not Acme's server supports nonces, and
      fail to perform any validation if it does not.

These two local security policies are both perfectly valid for many 
users, but the indirect question being asked is:  Are these the ONLY two 
security policies that v1 OCSP clients may permit users to choose.

I posit that there is a third local security policy that the MUST 
language prohibits, and that policy can be achieved under v1 SHOULD 
language:

   3) Send a nonce to Acme's server, and accept the response IFF
      the response contains the nonce OR the server SECURELY signals
      that it does not supply nonces to anyone.

There was plenty of discussion around the best way to achieve this 
secure signalling, but there was overwhelming consensus on this list 
that this should at least be a theoretical option.  By using SHOULD, you 
permit willing clients and servers to extend RFC2560 (that's what 
extensions are there for?) to adopt such an optional security model, 
rather than arbitrarily preventing all such extensibility.

No one is arguing that this third local security policy must be 
implemented by every client and server, but by adopting language using 
SHOULD instead of MUST, you will permit v1-compliant servers and clients 
to at least consider implementing such a policy before v2-final in a few 
years.

Content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 14:05:32 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Cc: "Carlisle Adams" <[email-masked]>
Sender: [email-masked]

I know this isn't a poll, but to be clear MSFT does not support the MUST
reject in v1, nor the creation of a v2 for the nonce reason alone.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Wednesday, November 26, 2003 12:05 PM
To: [email-masked]
Cc: Carlisle Adams
Subject: DISCUSS: MUST reject in OCSPv1

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.

Mike

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Carlisle Adams" <[email-masked]>
Subject: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 13:04:42 -0700
Importance: Normal
Sender: [email-masked]

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.

Mike

Date: Wed, 26 Nov 2003 14:53:01 -0500
From: jim <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Straw poll: An advice to a commercial CA
Sender: [email-masked]

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

Expensive preferred with mostly multiple is what we hear from our 
potential customer database
Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com

Anders Rundgren wrote:

>Well,
>Since the list is close to "vibrant" with emotions, why not
>put RFC3280 through the litmus test?
>
>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots
>
>Lets rock!
>
>/a
>
>----- Original Message ----- 
>From: "Stephen Kent" <[email-masked]>
>To: "Anders Rundgren" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Wednesday, November 26, 2003 15:55
>Subject: Re: Certificate Policy Standardization
>
>
>
>At 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  
>
>> >I am not what you mean by ".....another useless PKIX bloat extension".
>>
>>    
>>
>>>If properly used by the CA and relying party systems, the certificate policy
>>>OID can be used to provide amount of trust the relying party should place in
>>>a certificate.
>>>      
>>>
>>What Michael referred to as "bloat" is not policy identifiers themselves
>>but that they need another trust adminstration GUI and associated hassles.
>>
>>Policy identifiers used for path validation purposes is indeed a
>>very "fancy" thing from a technical point of view (maybe 2% of the
>>people subscribed to the PKIX list can understand this part of
>>RFC3280...), but from an interoperability point of view they are
>>not that great.
>>
>>Hum, there simply must be a reason why practically all commercial
>>CAs have selected an entirely different approach.  And that they did
>>this completely on their own without any commitee descision etc.
>>
>>I wonder how this really happend.   Could it be...
>>
>>    that it sort of feels "natural"?
>>
>>/a
>>    
>>
>
>could it be because some of them are clueless, as evidenced by 
>Peter's collection of non-compliant certs issued by these folks?
>
>could it be because these CAs like to create their own closed 
>communities to maintain market share?
>
>there are lots of good reasons for a CA to not use a feature in the 
>standards, a few good reasons to choose another way to achieve the 
>same effect, and lots of bad reasons to choose another way ...
>
>
>Steve
>
>
>
>  
>

--------------060903070805070703020909
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Expensive preferred with mostly multiple is what we hear from our potential
customer database<br>
Jim Heimberg, ABC, Ph.D.<br>
<b>Secure Course</b><br>
<a class="moz-txt-link-abbreviated" href="http://www.securecourse.com">www.securecourse.com</a><br>
<br>
Anders Rundgren wrote:<br>
<blockquote type="cite" cite="mid006601c3b44f$66f98330$0500a8c0@arport">
  <pre wrap="">Well,
Since the list is close to "vibrant" with emotions, why not
put RFC3280 through the litmus test?

Assume that you as PKI professionals would advice a commercial
TTP CA on how to configure their issuance for the following:
1. Free e-mail roundtrip-verification certficates.  Low insurance level
2. Expensive (high insurance level) multi-usage certificates for individuals
using strong verification procedures.

Note: the service is to be launched ASAP and has the only
objective, making money by serving its subscribers well.

Indicate your advice by the word in uppercase.

SINGLE: A single root + possibly some CP OIDs to spice things up
MULTIPLE: Different roots

Lets rock!

/a

----- Original Message ----- 
From: "Stephen Kent" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
To: "Anders Rundgren" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Sent: Wednesday, November 26, 2003 15:55
Subject: Re: Certificate Policy Standardization

At 10:03 +0100 11/26/03, Anders Rundgren wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap=""> &gt;I am not what you mean by ".....another useless PKIX bloat extension".

    </pre>
    <blockquote type="cite">
      <pre wrap="">If properly used by the CA and relying party systems, the certificate policy
OID can be used to provide amount of trust the relying party should place in
a certificate.
      </pre>
    </blockquote>
    <pre wrap="">What Michael referred to as "bloat" is not policy identifiers themselves
but that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a
very "fancy" thing from a technical point of view (maybe 2% of the
people subscribed to the PKIX list can understand this part of
RFC3280...), but from an interoperability point of view they are
not that great.

Hum, there simply must be a reason why practically all commercial
CAs have selected an entirely different approach.  And that they did
this completely on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a
    </pre>
  </blockquote>
  <pre wrap=""><!---->
could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...

Steve

  </pre>
</blockquote>
<br>
</body>
</html>

--------------060903070805070703020909--

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Straw poll: An advice to a commercial CA
Date: Wed, 26 Nov 2003 19:59:20 +0100
Sender: [email-masked]

Well,
Since the list is close to "vibrant" with emotions, why not
put RFC3280 through the litmus test?

Assume that you as PKI professionals would advice a commercial
TTP CA on how to configure their issuance for the following:
1. Free e-mail roundtrip-verification certficates.  Low insurance level
2. Expensive (high insurance level) multi-usage certificates for individuals
using strong verification procedures.

Note: the service is to be launched ASAP and has the only
objective, making money by serving its subscribers well.

Indicate your advice by the word in uppercase.

SINGLE: A single root + possibly some CP OIDs to spice things up
MULTIPLE: Different roots

Lets rock!

/a

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 26, 2003 15:55
Subject: Re: Certificate Policy Standardization

At 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  >I am not what you mean by ".....another useless PKIX bloat extension".
>
>>If properly used by the CA and relying party systems, the certificate policy
>>OID can be used to provide amount of trust the relying party should place in
>>a certificate.
>
>What Michael referred to as "bloat" is not policy identifiers themselves
>but that they need another trust adminstration GUI and associated hassles.
>
>Policy identifiers used for path validation purposes is indeed a
>very "fancy" thing from a technical point of view (maybe 2% of the
>people subscribed to the PKIX list can understand this part of
>RFC3280...), but from an interoperability point of view they are
>not that great.
>
>Hum, there simply must be a reason why practically all commercial
>CAs have selected an entirely different approach.  And that they did
>this completely on their own without any commitee descision etc.
>
>I wonder how this really happend.   Could it be...
>
>     that it sort of feels "natural"?
>
>/a

could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...

Steve

Date: Wed, 26 Nov 2003 13:35:42 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter,

Citing the critique from the Counterpane analysis of Ipsec and IKE 
from 5 years ago is a nice touch, but you should be aware that the 
non-IKE criticisms were largely refuted in messages on the IPsec 
list. Or, were you aware of that and did you simply choose to not 
share that part of the history with this list?

Unfortunately, the folks who performed the analysis were not protocol 
experts. They made assertions of what was wrong and how it should be 
fixed, and in most instances THEY were wrong. So, in this case, what 
we had were crypto experts offering protocol criticisms that they 
were not qualified to make. I hesitate to use the term "dummies" 
here, but its not all that far off, relative to the expertise that 
one should possess to be a good implementor.  In fact we had a repeat 
of this sort of argument in the last 12 months, when a capable 
cryptographer argued about how to use counter mode in IPsec, but 
without benefit of a deep understanding of assurance issues, FIPS 140 
evaluation, etc. Here too the non-dummy was just wrong in this 
context.

Sorry to spoil you rejoinder, but the facts don't support your 
position, and the cited text is just an example of smart folks who 
are not experts in the area in question getting it wrong.

Steve

Date: Wed, 26 Nov 2003 19:31:01 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

Peter has an xecellent point here.  I'm all in favor of "The rationale
behind this is..." a little here and there in some RFCs...

In message <[email-masked]> on Thu, 27 Nov 2003 05:59:48 +1300, [email-masked] (Peter Gutmann) said:

pgut001> Actually what I learn from this is that complex standards
pgut001> with often incomprehensible requirements are just asking for
pgut001> trouble if they don't include a rationale.  Even a single
pgut001> sentence explaining the background behind the SPD entry
pgut001> ordering would have prevented this in a manner that no amount
pgut001> of MUSTs/SHALLs ever can.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 27 Nov 2003 07:14:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  [...]

  [...]

  [...]

Peter.

Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

>the SPD entry ordering would have prevented this in a manner that no amount of

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve

Date: Wed, 26 Nov 2003 12:29:18 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Michael,

Do you believe any problems are solved by labeling of gasoline octane? 
The issuer of the gasoline advertises that it meets a certain technical 
specification, and each relying party decides what octane is required in 
his particular automobile.

With regard to granularity, some years ago there was a "Sunoco Custom 
Blending Pump" where you could dial up the exact quality of gasoline 
desired.  In my opinion, that's overkill - three grades is plenty. 
(Don't mention the different combinations of additives, which may vary 
by season, required by each of the 50 US states.  If any area cried out 
for policy standardization and granularity reduction, that is it.)

Three, coincidentally, is approximately the number of certificate 
policies actually used by the Department of Defense PKI.  Any number 
greater than two and less than six is a good number :-).

Dave

Michael Str�der wrote:

> Personally I'm not aware of any problems solved with the help of policy 
> OIDs. ;-) Maybe others on this list feel more enlightened.

Date: Wed, 26 Nov 2003 11:59:18 -0500
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave

Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
> 

Date: Thu, 27 Nov 2003 05:59:48 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

Peter.

Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 27 Nov 2003 04:13:30 +1300, [email-masked] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[email-masked]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 17:33:49 +0100
Sender: [email-masked]

<snip>

>that). 

Peter, this is basically what I call de-facto standard.  I.e.

                     CA <==> Policy

>So the trusted-roots mechanism does what the policy extension is
>supposed to do,

Here we approach the core issue.

The problem is that it is fully RCFxxxx-complient to issue
any number of technically- or legally-wise different certificates
(with or without embedded policy OIDs) under a given CA root.

That means, that using [most] existing RP software, you may end-up
"trusting" or processing things that you maybe _did_not_intend_to.
I.e. here we have a standards-sanctioned SECURITY HOLE and a
blatant INTEROPERABILITY DEFICIENCY of great magnitude.

How come this has never been addressed?
Because most PKIs are local and then it is an in-house issue.

The (non in-house) commercial CA sector have since years back
opted not to exploit a feature (multiple issuances/root) that:
- Is legally dangerous (much higher risk)
- Is technically not supported by applications
- Is hard to understand
- Does not solves a single _important_ problem
(that multiple CA keys would be a "problem" is simply ridiculous,
for whom would it be a problem?  Is policy OID config (if there
really was one....) "easier" than installing a root-key?

<snip>

>This is an almost complete inversion of

>  the certificate to that list.

Yes, and I believe all this should be reflected in a MAJOR update of RFC3280.
Not that I expect this to happen.  We'd better cling to the time-proven de-facto
methods, and continue to ignore standards that are not updated in spite of
having huge problems and close to zero acceptance in some very vital areas.

Anders

Date: Wed, 26 Nov 2003 10:44:51 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

>them were going to go through the full legal wringer.

Well, if people want to be masochistic I can't stop them :-)

Steve

Date: Thu, 27 Nov 2003 04:42:05 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter.

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Chris

Date: Thu, 27 Nov 2003 04:36:04 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

  
  [Snippage]

Peter.

From: "Hans Nilsson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 16:12:53 +0100
Sender: [email-masked]

I know of at least one CA product (SmartTrust Certificate Manager) which can
supports multiple issuance of certs (with different CPs) per CA root.

I know that this feature also is used by several of SmartTrust's customers,
for example for distinguishing between different issuing procedures and/or
private key storage media.

And when talking about Relying Party software, we do not usually mean
Outlook Express. After all, secure e-mail is not the number 1 PKI
application. 
Instead, RPs are usually servers, validating signatures in e-government and
e-banking applications. And RP software (from MS and others) can pick out
any field of a certificate and make a decision based on that.

Hans

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 2:30 PM
> To: [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> Hum,
> 
> I wonder how many times I have to repeat the same very basic
> questions and only getting answers back in "ASN.1"?  Sort of.
> So here we go again...
> 
> Because they have understood the problems associated?
> Because they enjoy "violating" standards?
> Because they are ignorant?
> Because their budget is too limited?
> Other?
> 
> Anders
> 
> ----- Original Message -----
> From: "Santosh Chokhani" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, November 26, 2003 12:04
> Subject: RE: Certificate Policy Standardization
> 
> 
> 
> Anders:
> 
> The relying parties are free to ignore the policies and policy related
> extensions altogether and verify paths.  The certification path will
verify
> unless:
> 
> 1.  One or more CAs in the path require that the certification path be
valid
> for a policy; or
> 
> 2.  Make the policy related extensions critical.
> 
> While some may view the two conditions as interoperability problem, I view
> it CA(s) saying that I do not want you to use the certificate unless you
> understand and abide by constraints I impose on the certificates.
> 
> The current X.509 and RFC 3280 permit you build PKI and applications that
do
> not use certificate policies.  So, I do not quite understand your concern
> below.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 4:03 AM
> To: Santosh Chokhani; [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> 
> 
> >I am not what you mean by ".....another useless PKIX bloat extension".
> 
> >If properly used by the CA and relying party systems, the certificate
> >policy OID can be used to provide amount of trust the relying party
> >should place in a certificate.
> 
> What Michael referred to as "bloat" is not policy identifiers themselves
but
> that they need another trust adminstration GUI and associated hassles.
> 
> Policy identifiers used for path validation purposes is indeed a very
> "fancy" thing from a technical point of view (maybe 2% of the people
> subscribed to the PKIX list can understand this part of RFC3280...), but
> from an interoperability point of view they are not that great.
> 
> Hum, there simply must be a reason why practically all commercial CAs have
> selected an entirely different approach.  And that they did this
completely
> on their own without any commitee descision etc.
> 
> I wonder how this really happend.   Could it be...
> 
>     that it sort of feels "natural"?
> 
> /a
> 

Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <025b01c3b421$683107b0$0500a8c0@arport> on Wed, 26 Nov 2003 14:30:06 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> I wonder how many times I have to repeat the same
anders.rundgren> very basic questions and only getting answers back in
anders.rundgren> "ASN.1"?  Sort of.  So here we go again...
anders.rundgren> 
anders.rundgren> 1. Why does practically no shrink-wrap PKI-enabled
anders.rundgren>    software package support any kind of certificate
anders.rundgren>    policy settings?
anders.rundgren> 
anders.rundgren> 2. And why do few if any commercial CAs support
anders.rundgren>    multiple issuances (i.e. different CPs) per CA
anders.rundgren>    root?
anders.rundgren> 
anders.rundgren> Because they have understood the problems associated?
anders.rundgren> Because they enjoy "violating" standards?
anders.rundgren> Because they are ignorant?
anders.rundgren> Because their budget is too limited?
anders.rundgren> Other?

Because they won't bother implementing something that a customer
hasn't asked for specifically.

I have literaly heard the sentence "Yeah, it would probably be useful
and might increase the value of our product, but no customer has said
they wanted or needed this, so we'll wait for that to happen".  And
this was for a product that had a lot to do with security.  It wasn't
about policy OIDs back then, but something similar enough.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 27 Nov 2003 04:13:30 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Peter.

Date: Wed, 26 Nov 2003 10:06:41 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

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

At 14:30 +0100 11/26/03, Anders Rundgren wrote:
>Hum,
>
>I wonder how many times I have to repeat the same very basic
>questions and only getting answers back in "ASN.1"?  Sort of.
>So here we go again...
>

one might ask why the most widely distributed product that claims to 
implement IPsec  (Windows) does not provide a user/administrator the 
ability to order SPD entries, as required by RFC 2401. The answer is 
that the implementors did not understand why this was an important 
(in the case of IPsec, a critical) aspect of the standard and so the 
implementors omitted an important management control.

what one can learn from this an similar examples is that vendors are 
a very poor basis for determining the worth of a feature in a 
standard. a very big vendor can screw up an implementation and get 
away with it due to market dominance. other vendors, eager to be 
compatible with the dominant vendor, follow suit.  most users may not 
understand a complex technology and don't know what's missing.

>Because they have understood the problems associated?

sometimes, but rarely, in my experience.

>Because they enjoy "violating" standards?

"enjoy" is probably the wrong term, but "don't care" is accurate.

>Because they are ignorant?

sometimes, yes!

>Because their budget is too limited?

prioritization of development resources, combined with time to market 
pressure is often the reason that a vendor omits certain features.

>Other?

yes, you left out implementors who have decided that in the market 
niche of interest to them, they have a "better" way of implementing a 
capability that is incompatible with the standard and so they pursue 
their proprietary approach.

Steve
--============_-1142263285==_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 Policy
Standardization</title></head><body>
<div>At 14:30 +0100 11/26/03, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>Hum,<br>
<br>
I wonder how many times I have to repeat the same very basic<br>
questions and only getting answers back in &quot;ASN.1&quot;?&nbsp;
Sort of.<br>
So here we go again...<br>
<br>
1. Why does practically no shrink-wrap PKI-enabled software<br>
package support any kind of certificate policy settings?</blockquote>
<div><br></div>
<div>one might ask why the most widely distributed product that claims
to implement IPsec&nbsp; (Windows) does not provide a
user/administrator the ability to order SPD entries, as required by
RFC 2401. The answer is that the implementors did not understand why
this was an important (in the case of IPsec, a<u> critical</u>) aspect
of the standard and so the implementors omitted an important
management control.</div>
<div><br></div>
<div>what one can learn from this an similar examples is that vendors
are a very poor basis for determining the worth of a feature in a
standard. a very big vendor can screw up an implementation and get
away with it due to market dominance. other vendors, eager to be
compatible with the dominant vendor, follow suit.&nbsp; most users may
not understand a complex technology and don't know what's
missing.</div>
<div><br></div>
<blockquote type="cite" cite>2. And why do few if any commercial CAs
support multiple<br>
issuances (i.e. different CPs) per CA root?<br>
<br>
Because they have understood the problems associated?</blockquote>
<div><br>
sometimes, but rarely, in my experience.<br>
</div>
<blockquote type="cite" cite>Because they enjoy &quot;violating&quot;
standards?</blockquote>
<div><br></div>
<div>&quot;enjoy&quot; is probably the wrong term, but &quot;don't
care&quot; is accurate.</div>
<div><br></div>
<blockquote type="cite" cite>Because they are ignorant?</blockquote>
<div><br></div>
<div>sometimes, yes!</div>
<div><br></div>
<blockquote type="cite" cite>Because their budget is too
limited?</blockquote>
<div><br></div>
<div>prioritization of development resources, combined with time to
market pressure is often the reason that a vendor omits certain
features.</div>
<div><br></div>
<blockquote type="cite" cite>Other?</blockquote>
<div><br></div>
<div>yes, you left out implementors who have decided that in the
market niche of interest to them, they have a &quot;better&quot; way
of implementing a capability that is incompatible with the standard
and so they pursue their proprietary approach.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1142263285==_ma============--

Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <028101c3b424$7dd4b460$0500a8c0@arport> on Wed, 26 Nov 2003 14:52:10 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Richard,

Anders,

anders.rundgren> That external parties to the US e-governments, like
anders.rundgren> various businesses would ever (on a wider scale)
anders.rundgren> bother with cross-certification is unlikely, they
anders.rundgren> will just purchase a TTP-issued "business
anders.rundgren> certificate" for a few hundred dollars, not run CAs.

Wait, weren't you just asking about connecting different PKIs
together, or did I misunderstand you?  Going out shopping "business
certificates" will mean absolutely nothing in terms of PKI connection
unless everyone agrees to shop from the same CA.  I see that
happening, right...

It's true that smaller businesses will most likely not bother running
their own CA (unless they are run by techno-geeks like me, but that's
a different matter :-)).  I'm not so sure about larger ones...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

At 12:05 +0100 11/26/03, Anders Rundgren wrote:
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...

Date: Wed, 26 Nov 2003 16:00:56 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <014b01c3b416$b6075580$0500a8c0@arport> on Wed, 26 Nov 2003 13:13:32 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> >I don't see how you can say that, Anders. That's not
anders.rundgren> >how the system is designed to work. No CA s/w that I
anders.rundgren> >have yet to encounter limits certificates to a
anders.rundgren> >single policy, let alone the CA. CertificatePolicies
anders.rundgren> >can be multivalued, is not a mandatory field, does
anders.rundgren> >not get marked as critical and in all except bespoke
anders.rundgren> >applications is currently ignored. Failure on the
anders.rundgren> >part of software developers to meet the agreed
anders.rundgren> >standards does not always indicate a failing of the
anders.rundgren> >standard (granted that in some cases it does).
anders.rundgren> 
anders.rundgren> Well Chris,
anders.rundgren> I think you read this in big haste.
anders.rundgren> 
anders.rundgren> CA s/w is not equivalent to RP s/w.
anders.rundgren> 
anders.rundgren> Please tell me where I in the latest edition of
anders.rundgren> Outlook Express (I'm indeed a daring guy...), can
anders.rundgren> "tweak" the CA policy trust settings.

That's today.  I believe that to the crowd, awareness of the type of
trust we're discussing here is fairly new (and in many cases so new
they aren't aware yet).  And M$ is fairly well-known for implementing
what it thinks the crowd wants and try to avoid things that could be
seen as complicated ("oh, I should protect my private key with a pass
phrase???"), so pardon me for rejecting that particular example.

I believe that when the crowd becomes a bit more aware of what their
actions mean when done through a computer, compared to the "real
world", they might demand  certain amount of control, and it's
perfectly possible that you will see those kinds of "knobs" sometime
in the future.

anders.rundgren> In case you don't find the "knob", does this in your
anders.rundgren> opinion mean that Microsoft is not
anders.rundgren> standards-compliant w.r.t. policy-OIDs?

Nope, it just means that they have assumed you would always press the
"Accept any policy" knob, and besides, that's all they currently
support, so the knob would be quite lonely in that otherwise empty
space, so they won't bother to put it up yet.

However, if M$ doesn't check for policy OID and mappings and keep
track of those along with the other data while verifying the path,
then they aren't standards-compliant w.r.t. policy OIDs.  As it is
right now, I wouldn't be surprised if they're in good company :-/.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 26 Nov 2003 09:55:40 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

At 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  >I am not what you mean by ".....another useless PKIX bloat extension".
>
>>If properly used by the CA and relying party systems, the certificate policy
>>OID can be used to provide amount of trust the relying party should place in
>>a certificate.
>
>What Michael referred to as "bloat" is not policy identifiers themselves
>but that they need another trust adminstration GUI and associated hassles.
>
>Policy identifiers used for path validation purposes is indeed a
>very "fancy" thing from a technical point of view (maybe 2% of the
>people subscribed to the PKIX list can understand this part of
>RFC3280...), but from an interoperability point of view they are
>not that great.
>
>Hum, there simply must be a reason why practically all commercial
>CAs have selected an entirely different approach.  And that they did
>this completely on their own without any commitee descision etc.
>
>I wonder how this really happend.   Could it be...
>
>     that it sort of feels "natural"?
>
>/a

could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...

Steve

Date: Wed, 26 Nov 2003 09:49:16 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 19:07 +1300 11/26/03, Peter Gutmann wrote:
>>Note that with the advent of 3280, we decided to let protocols that are PKI
>>clients define extended key usage options for themselves.
>
>I recently had to deal with someone who's working with certs from (at least)
>two difference (largeish) public CAs.  One CA turned the eKU into a kind of
>lamp test packet, with every usage they could think of set ("Let's see, what
>have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
>and S/MIME, that sounds like a sensible combination of usages for a private
>key").  The other CA didn't populate the eKU at all, justifying it with
>"Everything ignores those anyway, so it doesn't matter what you put in there"
>(obviously they have to ignore them, in order to allow certs like the ones I'm
>describing to function).  In the end after taking legal considerations into
>account the conclusion was to define a new eKU, "doWhatISay", defined as "This
>key may only be used as we say it can be used" (it's not quite worded like
>that in their CPS, that'll take another six months for the lawyers to sort
>out).
>
>I dunno about the situation in the PKIX reality, but in the real world from
>the legal point of view (which is what matters in the end) that's about the
>best way to make use of eKU.
>
>Peter.

Your example is one in which CAs chose to make up their own, private 
EKUs. This is certainly allowed, but it is not what I said we had 
decided to do in the IETF, where we would expect EKU OIDs to be 
standardized by the cognizant WGs for the protocols with which the 
certs are used.

Also, you claim that what matters in the end is what "the legal point 
of view" says.  This is certainly true in some contexts, but not all 
certs are used in ways that have legal ramifications of the sort you 
imply. For example, most certs used with IKE will not be subject to 
some attorney's advice, I suspect.

Steve

Date: Wed, 26 Nov 2003 09:19:55 -0500
From: jim <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Richard brings up an excellent point that should be considered by the 
members of this body.  On the horizon is the implementation of security 
middleware from a number of sources, which will allow for simpler 
PKEnablement of Web applications.  The issue in this regard is going to 
be the identification of how trust can be shared without having to go 
back to the original CA who issued a cert and cross-certifying CAs in 
that regard so that Internet commerce can be accomplished with many uses 
on the fly from disparate PKIs.  Meaningful OIDs offer a lot that can 
increase the success or failure of PK technology adaptation for 
commerce.  In that regard, please everyone, see what you can think of 
that will make this a useful and helpful solution to allow PK technology 
to flourish.

Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com

Richard Levitte - VMS Whacker wrote:

>In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[email-masked]> said:
>
>anders.rundgren> Policy OIDs may be "perfect" as long as you stay
>anders.rundgren> inside of your "walled garden", but the USs
>anders.rundgren> government PKI will likely find itself up the creek
>anders.rundgren> when they are going to connect to the outside world
>anders.rundgren> who hardly ever use this feature (which I BTW cannot
>anders.rundgren> find a single "knob" for in my W2K system), or even
>anders.rundgren> worse, have settled on another set of OIDs.
>
>Uhmm, especially that last thing about other PKIs having other sets
>of OIDs makes me think you have missed the mechanism called "policy
>mapping".  There's no requirement whatsoever that everyone uses the
>same set of OIDs.  However, if the owner of one PKI decides to do
>business with another PKI owner and have the two PKIs connected, they
>will typically do some cross certification, and those certificates
>will contain the appropriate mappings of policies, as decided by the
>two parties together.
>
>As far as I understand, those kinds of mechanisms are already in use
>and working.  I assume others here will be able to say yay or ney
>about this matter.
>
>Of course, what I said above implies some level of "meshness", about
>which I've read some negative comments from one person...
>
>-----
>Please consider sponsoring my work on free software.
>See http://www.free.lp.se/sponsoring.html for details.
>You don't have to be rich, a $10 donation is appreciated!
>
>  
>

Date: Wed, 26 Nov 2003 15:18:12 +0100
From: Andreas Mitrakas <[email-masked]>
Subject: Re: Certificate Policy Standardization
To: Anders Rundgren <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Hello Anders,

> As I wrote I don't object to policy OIDs themselves, but to their use in
> path validation and their configaration in RP applications.

Much like yourself and regardless of preferences, all I am saying is that one
should be apprehensive as to what a CP is all about, since CPs have legal as
well as technical and organisational significance . Especially so in some
implementations in Europe where there is a direct link between the policy and
the law under which certain certs like QC certs are issued. A CP becomes part
of the parties agreement and binding by means of e.g. a subscriber agreement.
So it is not unthinkable albeit not necessarily desirable, that a courts
might  scrutinise policies. --God forbid.

> Regarding your comment I think this is a bit wrong.  What good is
> a CP OID (basically) saying "I come from a good CA"?  "Good" is
> IMHO for others to vouch for.  Uncertified or unverified data is pretty
> useless for trust purposes.

All I am saying is that establishing a trustworthy source of CP information
makes good sense so that RPs are notified of changes in CP versions and they
stand a chance to scan CPs before they are forced to accept the next cert in
the line. An OID can help but it does not necessarily solve the problem of a
trustworthy source for policies because then someone has to manage such a
repository.

andreas

From: "Anders Rundgren" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:52:10 +0100
Sender: [email-masked]

Richard,
That external parties to the US e-governments, like various
businesses would ever (on a wider scale) bother with cross-
certification is unlikely, they will just purchase a TTP-issued
"business certificate" for a few hundred dollars, not run CAs.

And in the case of the US e-government, they have a much more
serious problem to cater for than CP OIDs and that is that their
business parties, will authenticate messages at the business partner
level, not on employee level (as the latter is incompatible with
all e-business systems I have heard about).  So they probably
have to take down the whole thing and startover anyway.
Or have "gateway" servers do the transformation from their
internal "mess-PKI" (not mesh PKI) to something that works.
Like "flat", "boring", "simple",  you know.  In that world
CP OIDs are mostly unknown.   I have yet to find a CP OID
in my fairly new Thawte SSL certificate.

Anders

----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 26, 2003 14:30
Subject: Re: Certificate Policy Standardization

In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[email-masked]>
said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Nov 2003 13:41:30 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Agreed

Chris

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:30:06 +0100
Sender: [email-masked]

Hum,

I wonder how many times I have to repeat the same very basic
questions and only getting answers back in "ASN.1"?  Sort of.
So here we go again...

Because they have understood the problems associated?
Because they enjoy "violating" standards?
Because they are ignorant?
Because their budget is too limited?
Other?

Anders

----- Original Message ----- 
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 26, 2003 12:04
Subject: RE: Certificate Policy Standardization

Anders:

The relying parties are free to ignore the policies and policy related
extensions altogether and verify paths.  The certification path will verify
unless:

1.  One or more CAs in the path require that the certification path be valid
for a policy; or

2.  Make the policy related extensions critical.

While some may view the two conditions as interoperability problem, I view
it CA(s) saying that I do not want you to use the certificate unless you
understand and abide by constraints I impose on the certificates.

The current X.509 and RFC 3280 permit you build PKI and applications that do
not use certificate policies.  So, I do not quite understand your concern
below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: Wednesday, November 26, 2003 4:03 AM
To: Santosh Chokhani; [email-masked]
Subject: Re: Certificate Policy Standardization

>I am not what you mean by ".....another useless PKIX bloat extension".

>If properly used by the CA and relying party systems, the certificate 
>policy OID can be used to provide amount of trust the relying party 
>should place in a certificate.

What Michael referred to as "bloat" is not policy identifiers themselves but
that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a very
"fancy" thing from a technical point of view (maybe 2% of the people
subscribed to the PKIX list can understand this part of RFC3280...), but
from an interoperability point of view they are not that great.

Hum, there simply must be a reason why practically all commercial CAs have
selected an entirely different approach.  And that they did this completely
on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a

Date: Wed, 26 Nov 2003 14:30:17 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 13:13:32 +0100
Sender: [email-masked]

>> In case you are advising people setting up CAs, I would (in case the
>> CP OID stuff stays forever in the backburner), also recommend them
>> to only apply one CP per CA root, as anything else is actually
>> incompatible with some 99.9% of existing RP software.

>I don't see how you can say that, Anders. That's not how the system
>is designed to work. No CA s/w that I have yet to encounter limits
>certificates to a single policy, let alone the CA. CertificatePolicies
>can be multivalued, is not a mandatory field, does not get marked as
>critical and in all except bespoke applications is currently ignored.
>Failure on the part of software developers to meet the agreed standards
>does not always indicate a failing of the standard (granted that in
>some cases it does).

Well Chris,
I think you read this in big haste.

Also please show me a single commercial CA that uses multiple
CPs for a certain root.  Note, multi-valued or not that does not matter,
because that is another thing.

A bit puzzled
Anders

Date: Thu, 27 Nov 2003 01:15:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Sender: [email-masked]

"Anders Rundgren" <[email-masked]> writes:

>  The "market", "crowd", or whatever we name it will never ever
>  know what a "Certificate Policy" is.  And they are perfectly right!

Actually I think they understand very well what it means, it's a large hammer
that you give to your lawyers so they can go after misbehaving (as defined by
the CA) users.  What the RP makes of the policy doesn't really matter, since
it's written by corporate lawyers acting for the CA, not by ones acting for
the RP or ones who have their interests in mind.

(Incidentally, the previous message that I replied to wasn't actually written
 by Anders, I'd already deleted the mail, then decided that it really needed
 replying to and patched it together from the scrollback buffer, which ended
 up with it misattributed.  Apologies for the confusion).

Peter.

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Nov 2003 11:53:45 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

> In case you are advising people setting up CAs, I would (in case the
> CP OID stuff stays forever in the backburner), also recommend them
> to only apply one CP per CA root, as anything else is actually
> incompatible with some 99.9% of existing RP software.

I don't see how you can say that, Anders. That's not how the system
is designed to work. No CA s/w that I have yet to encounter limits
certificates to a single policy, let alone the CA. CertificatePolicies
can be multivalued, is not a mandatory field, does not get marked as
critical and in all except bespoke applications is currently ignored.
Failure on the part of software developers to meet the agreed standards
does not always indicate a failing of the standard (granted that in
some cases it does).

Chris

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Richard Levitte - VMS Whacker" <[email-masked]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:31:19 +0100
Sender: [email-masked]

>For me, OIDs are yet to have their time. As a concept they are elegant
>but will resist widespread use until security-exploiting applications
>support them. Until then they are destined to stay on the back-burner.

Sure.

>I encourage people to adopt their use, however, if only to future-proof
>themselves and I don't see any harm whatsoever in embedding in a certificate
>some mechanism that links the trust level it represents to a real-world
>legal mechanism, even if at present the software support for such a link
>is absent.

In case you are advicing people setting up CAs, I would (in case the
CP OID stuff stays forever in the backburner), also recommend them
to only apply one CP per CA root, as anyhting else is actually
incompatible with some 99.9% of existing RP software.

/anders

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Da Capo: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:05:26 +0100
Sender: [email-masked]

>applicable policy might render that CP unenforceable.

When I read a statement like above, I get really sad and begin
to completely lose faith in the PKI technology [1], wondering
if I maybe should go and waste my talent on something useful
for a change.

=================================================
  The "market", "crowd", or whatever we name it will never ever
  know what a "Certificate Policy" is.  And they are perfectly right!
=================================================

If you can spell to the word "Issuer", you are probably a "guru" in their eyes.

Now I feel a little bit better :-)

Anders R

1] or rather in the clueless "high priests" who "guards" it...

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 06:04:14 -0500
Importance: Normal
Sender: [email-masked]

Anders:

The relying parties are free to ignore the policies and policy related
extensions altogether and verify paths.  The certification path will verify
unless:

1.  One or more CAs in the path require that the certification path be valid
for a policy; or

2.  Make the policy related extensions critical.

While some may view the two conditions as interoperability problem, I view
it CA(s) saying that I do not want you to use the certificate unless you
understand and abide by constraints I impose on the certificates.

The current X.509 and RFC 3280 permit you build PKI and applications that do
not use certificate policies.  So, I do not quite understand your concern
below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: Wednesday, November 26, 2003 4:03 AM
To: Santosh Chokhani; [email-masked]
Subject: Re: Certificate Policy Standardization

>I am not what you mean by ".....another useless PKIX bloat extension".

>If properly used by the CA and relying party systems, the certificate 
>policy OID can be used to provide amount of trust the relying party 
>should place in a certificate.

What Michael referred to as "bloat" is not policy identifiers themselves but
that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a very
"fancy" thing from a technical point of view (maybe 2% of the people
subscribed to the PKIX list can understand this part of RFC3280...), but
from an interoperability point of view they are not that great.

Hum, there simply must be a reason why practically all commercial CAs have
selected an entirely different approach.  And that they did this completely
on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a

Date: Wed, 26 Nov 2003 23:55:41 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter.

From: "Anders Rundgren" <[email-masked]>
To: "Andreas Mitrakas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 11:15:54 +0100
Sender: [email-masked]

>applicable policy might render that CP unenforceable.

As I wrote I don't object to policy OIDs themselves, but to their use in
path validation and their configaration in RP applications.

Regarding your comment I think this is a bit wrong.  What good is
a CP OID (basically) saying "I come from a good CA"?  "Good" is
IMHO for others to vouch for.  Uncertified or unverified data is pretty
useless for trust purposes.

But if a CP OID says "I am an e-mail certificate" you could probably
use this information.  Assuming that you trust the CA...

This is why I claim that a useful CP OID system should never ever
mix tech-stuff with legal-stuff.  But that has already been done by for
example the US government.  Poor suckers!

Anders

From: [email-masked]
To: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Cc: [email-masked], Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 09:31:26 +0000
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

> Personally I'm not aware of any problems solved with the help of policy
> OIDs. ;-) Maybe others on this list feel more enlightened.

For me, OIDs are yet to have their time. As a concept they are elegant
but will resist widespread use until security-exploiting applications
support them. Until then they are destined to stay on the back-burner.
I encourage people to adopt their use, however, if only to future-proof
themselves and I don't see any harm whatsoever in embedding in a certificate
some mechanism that links the trust level it represents to a real-world
legal mechanism, even if at present the software support for such a link
is absent.

Chris

Date: Wed, 26 Nov 2003 10:31:51 +0100
From: Andreas Mitrakas <[email-masked]>
Subject: Re: Certificate Policy Standardization
To: Anders Rundgren <[email-masked]>
Cc: Steve Hanna <[email-masked]>, [email-masked]
Sender: [email-masked]

The mere fact that ETSI TS 101 456 for example mandates policy OIDs, does
not necessarily mean that the CP that features them is enforceable at all
times, simply because there might be something wrong with the rest of the
terms that voids the whole CP.

The obvious risk for the transacting parties can be unwarranted
transaction that threaten to render unenforceable legitimate practices.

andreas

Anders Rundgren wrote:

> >>Michael Str�der wrote:
> >> Again this boils down to policy OIDs just being
> >> another useless PKIX bloat extension.
>
> >One man's bloat is another man's critical feature.
>
> The problem is that you have two mechanisms for essentially
> doing the same thing with respect to the RP.  Personally I care
> much more about RPs than CAs as RPs usually outnumber
> CAs by a magnitude or more.
>
> Policy OIDs may be "perfect" as long as you stay inside of your
> "walled garden", but the USs government PKI will likely find itself up
> the creek when they are going to connect to the outside world who
> hardly ever use this feature (which I BTW cannot find a single
> "knob" for in my W2K system), or even worse, have settled on
> another set of OIDs.
>
> I would go as far as suggesting that a revised RFC3280 could
> possible even deprecate the policy stuff except for CAs/PKIs
> targetting a restricted "community".
>
> A part from this, I believe the design of the policy system leaves
> quite a bit to be desired, as a useful system should be parameterized
> so that you don't mix technical stuff  like (S/MIME, SSL) with
> more policy-like things like "quality" etc.  Note:  I don't want
> to see such a work, but if I believed in CP OIDs, this is how
> I would do...
>
> Anders

From: "Anders Rundgren" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 10:03:08 +0100
Sender: [email-masked]

>I am not what you mean by ".....another useless PKIX bloat extension".

>If properly used by the CA and relying party systems, the certificate policy
>OID can be used to provide amount of trust the relying party should place in
>a certificate.

What Michael referred to as "bloat" is not policy identifiers themselves
but that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a
very "fancy" thing from a technical point of view (maybe 2% of the
people subscribed to the PKIX list can understand this part of
RFC3280...), but from an interoperability point of view they are
not that great.

Hum, there simply must be a reason why practically all commercial
CAs have selected an entirely different approach.  And that they did
this completely on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a

Date: Tue, 25 Nov 2003 16:48:06 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Richard Levitte - VMS Whacker <[email-masked]>
Cc: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Richard Levitte - VMS Whacker wrote:
> Michael Str�der <[email-masked]> said:
> 
> michael> >  It's not much different
> michael> > from, say, adding another public key to your PGP key ring annd
> michael> > applying trust to it...  It can be done in a cluelessly with no
> michael> > checks, or in a clued-in way with checks.
> michael> 
> michael> But the question raised here was what we will gain with
> michael> certificate policy OIDs.
> 
> Granularity,

Even more granularity? ;-)

> and a resolution to the question "can this certificate be
> used for this $10M transaction" (and other similar questions)...

I'm not a financial specialist. But IMO this kind of assertion cannot be 
generally made in a certificate. E.g. you won't be able to convince a bank 
to vouch for a $10M transaction without explaining the specific business 
case to them. As I learned from a former job shipping goods for $10M from 
Asia to Europe is a complex business process of approx. 20 steps involving 
several banks, lawyers, complicated contracts, tax and trading laws, etc. 
Well, after explaining such a business case to your bank asking for a credit 
you don't need a certificate at all.

That's why I didn't pay any attention to the warranty extension draft. 
There's no real-world use-case for it.

> After all, the problem that was "solved" with policy OIDs was the fact
> that all certificates were assumed to be equal under one (unwritten?)
> policy, correct?

Personally I'm not aware of any problems solved with the help of policy 
OIDs. ;-) Maybe others on this list feel more enlightened.

> just as mesh PKIs aren't really supported by
> quite a lot of software

I consider lack of support for mesh PKIs to be a good thing.

> michael> > michael> Or a browser vendor charging CAs for placing their
> michael> > michael> root CA cert in the default installation. Or...
> michael> > 
> michael> > That's a different story, and an action that generates such
> michael> > feelings in me that I lack words to express them (not happy
> michael> > feelings, I can tell you that).
> michael> 
> michael> Guess what would happen with certificate policy OIDs if
> michael> widely deployed.
> 
> Well, how do you solve that?  If things are this bad (and it's not
> something we know for sure, although guessing it is doesn't feel too
> far-fetched), it will stay that way whatever is invented.

Yes, it will stay this way. There's nothing we can do about this at the 
technical level. That's what security architects should take into account 
more often.

Ciao, Michael.

Date: Wed, 26 Nov 2003 19:07:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>Note that with the advent of 3280, we decided to let protocols that are PKI
>clients define extended key usage options for themselves.

I recently had to deal with someone who's working with certs from (at least)
two difference (largeish) public CAs.  One CA turned the eKU into a kind of
lamp test packet, with every usage they could think of set ("Let's see, what
have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
and S/MIME, that sounds like a sensible combination of usages for a private
key").  The other CA didn't populate the eKU at all, justifying it with
"Everything ignores those anyway, so it doesn't matter what you put in there"
(obviously they have to ignore them, in order to allow certs like the ones I'm
describing to function).  In the end after taking legal considerations into
account the conclusion was to define a new eKU, "doWhatISay", defined as "This
key may only be used as we say it can be used" (it's not quite worded like
that in their CPS, that'll take another six months for the lawyers to sort
out).

I dunno about the situation in the PKIX reality, but in the real world from
the legal point of view (which is what matters in the end) that's about the
best way to make use of eKU.

Peter.

From: "Santosh Chokhani" <[email-masked]>
To: [email-masked]
Subject: RE: Certificate Policy Standardization
Date: Tue, 25 Nov 2003 10:11:59 -0500
Importance: Normal
Sender: [email-masked]

Michael:

I am not what you mean by ".....another useless PKIX bloat extension".

If properly used by the CA and relying party systems, the certificate policy
OID can be used to provide amount of trust the relying party should place in
a certificate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Str�der
Sent: Tuesday, November 25, 2003 2:41 AM
To: Steve Hanna
Cc: Anders Rundgren; [email-masked]
Subject: Re: Certificate Policy Standardization

Steve Hanna wrote:
> Applications can use certificate policy OIDs to make
> trust decisions today. The application just needs to
> have a way for the user or administrator to configure
> the list of acceptable certificate policies (called
> the user-initial-policy-set in RFC 3280).

Which is as bad as the user or administrator installing trusted root CA 
certs. Or a browser vendor charging CAs for placing their root CA cert in 
the default installation. Or...

Again this boils down to policy OIDs just being another useless PKIX bloat 
extension.

Ciao, Michael.

Date: Tue, 25 Nov 2003 09:51:19 -0500
To: "Richard Levitte - VMS Whacker" <[email-masked]>
From: "Stephen Kent" <[email-masked]>
Subject: Re: Certificate Policy Standardization
cc: [email-masked]
Sender: [email-masked]

>
>
>michael> Again this boils down to policy OIDs just being another
>michael> useless PKIX bloat extension.
>
>Uhmm, I might be historically clueless here: are policy OIDs really a
>PKIX invention?
>
Policy OIDs are part of X.509, not a PKIX invention.  The complaint 
is just the usual carping about standards, with inaccurate 
attribution. In Michael's world view blame can be distributed 
universally, at least in the direction of others :-)

Steve

Date: Tue, 25 Nov 2003 09:41:27 -0500
From: "Steve Hanna" <[email-masked]>
To: "Michael =?iso-8859-1?Q?Str=F6der?=" <[email-masked]>
cc: "Anders Rundgren" <[email-masked]>, [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msD0C286071AFEC49362983560
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael Str�der wrote:
> Again this boils down to policy OIDs just being
> another useless PKIX bloat extension.

One man's bloat is another man's critical feature.

Some user communities don't care much about certificate
policy or have only one policy for their whole PKI.
They don't need policy OIDs. Other user communities
(especially government) want to support multiple
policies within a single PKI. For them, policy OIDs
are perfect.

I'm afraid that your perspective on PKI is too narrow.

Thanks,

Steve
--------------msD0C286071AFEC49362983560
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

--------------msD0C286071AFEC49362983560--

Date: Tue, 25 Nov 2003 09:43:43 -0500
To: "todd glassey" <[email-masked]>
From: "Stephen Kent" <[email-masked]>
Subject: Re: Certificate Policy Standardization
cc: [email-masked]
Sender: [email-masked]

At 17:56 -0800 11/24/03, todd glassey wrote:
>Charter or not Stephen - its something that is critically missing in all
>eBusiness processes. That being some uniform method of invoking the coverage
>of eSign acts and some method of specifying in the transaction receipt, what
>jurisdiction the specific act is done under.
>
>That you done want this as part of PKIX is also not relevant as to whether
>its needed, only to whether PKIX is allowed to focus on it.
>
>Todd :-)

Todd,

The relevant discussion for this list is whether the formulation of 
such policies, their publication, and assignment of OIDs is a PKIX 
topic.  The answer is NO to all three of these possible activities, 
in the PKIX context.

If you are convinced this is an important problem, take it to a forum 
when you can pursue it.

Steve

P.S.  I am totally unconvinced that we require a standard set of 
policies to be established by a standards organization like the IETF, 
ITU, ASMI, etc.  As others have noted, CAs are free to create their 
own and they usually do. If I were operating an EDI net of some sort 
I might create one for that context and operate a CA for the 
subscribers.  At most one needs to register OIDs to avoid collisions. 
But, reference to a CPS can be effected via out-of-band means, or via 
a proprietary extension; there are lots of ways people deal with this 
issue today.

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: TSA certificate content
Date: Tue, 25 Nov 2003 09:56:59 -0600
Importance: Normal
Sender: [email-masked]

I think key usage is not relevant here, can even be absent. The relevant
one is the EKU extension. That's how we do it in our implementation.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Sylvester
> Sent: Monday, November 24, 2003 7:30 AM
> To: [email-masked]
> Subject: TSA certificate content
> 
> 
> 
> I would like to hear some opinion about the setting
> of the extension keyUsage in a certificate for a
> 3161 TSA.
> 
> The question is whether a certificate contain no
> keyUsage extension at all and only an extended
> key usage with the appropriate key purpose
> is conformant with 3161 and 3280.
> 
> Peter

Date: Tue, 25 Nov 2003 10:42:30 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: meeting minutes, slides
Sender: [email-masked]

I have received comments on the draft minutes from several folks, and 
have made the requested corrections.  The final version of the 
minutes has just been sent to the secretariat, and will be available 
on the IETF web site, in December. The slides presented during the 
meeting also have been submitted for posting.

Steve

Date: Tue, 25 Nov 2003 10:18:09 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG last call: draft-pkix-acpolicies-extn-03.txt
Cc: [email-masked], [email-masked], Denis Pinkas <[email-masked]>
Sender: [email-masked]

Denis & Chris

I have reviewed the new document and am satisfied that all WG comments have 
been addressed.

The only outstanding issues identified on the list are the ASN.1 reference 
identified by Jim Schaad and inserting the  OIDs  assigned by Russ Housley.

However, I reviewed the "ID nits" (see http://www.ietf.org/ID-nits.html) 
and identified a number of minor issues that also need to be addressed:

(1) The current Abstract needs to be expanded; the requirement is that the 
abstract "be meaningful to someone not versed in the technology".
(2) Please keep RFC 3280 in the Normative References section.  Please 
create an Informative References section and move the ISO X.509 
specification to that section.
(3) Please add an IPR section and include the IPR notices in RFC 2026 
10.4(a) and 10.4(b). (See http://www.ietf.org/rfc/rfc2026.txt for the exact 
text.) [Note: To my knowledge, no IPR claims are known.  If that is not 
correct, please add 10.4(d) and let me know ASAP if we need to get an IPR 
notice filed with the IESG.]
(4) Please give some thoughts to your security considerations.  I believe 
they need to be expanded.  For example, I believe you should re-emphasize 
that trusting policy alone is insufficient.  The relying party must 
determine that the AC has the appropriate policy and was issued by a 
trusted AA.  I believe that all the security considerations for RFC 3281 
still apply, that might be worth adding.

Please submit a new draft that resolves the ASN.1 issues and the four 
issues that I have identified.  That draft will be forwarded to the ADs for 
consideration by the IESG.

Thanks,

Tim Polk

From: "Anders Rundgren" <[email-masked]>
To: "Steve Hanna" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Tue, 25 Nov 2003 16:11:57 +0100
Sender: [email-masked]

>>Michael Str�der wrote:
>> Again this boils down to policy OIDs just being
>> another useless PKIX bloat extension.

>One man's bloat is another man's critical feature.

The problem is that you have two mechanisms for essentially
doing the same thing with respect to the RP.  Personally I care
much more about RPs than CAs as RPs usually outnumber
CAs by a magnitude or more.

Policy OIDs may be "perfect" as long as you stay inside of your
"walled garden", but the USs government PKI will likely find itself up
the creek when they are going to connect to the outside world who
hardly ever use this feature (which I BTW cannot find a single
"knob" for in my W2K system), or even worse, have settled on
another set of OIDs.

I would go as far as suggesting that a revised RFC3280 could
possible even deprecate the policy stuff except for CAs/PKIs
targetting a restricted "community".

A part from this, I believe the design of the policy system leaves
quite a bit to be desired, as a useful system should be parameterized
so that you don't mix technical stuff  like (S/MIME, SSL) with
more policy-like things like "quality" etc.  Note:  I don't want
to see such a work, but if I believed in CP OIDs, this is how
I would do...

Anders

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Policy Standardization
Date: Tue, 25 Nov 2003 10:11:59 -0500
Importance: Normal
Sender: [email-masked]

Michael:

I am not what you mean by ".....another useless PKIX bloat extension".

If properly used by the CA and relying party systems, the certificate policy
OID can be used to provide amount of trust the relying party should place in
a certificate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Str�der
Sent: Tuesday, November 25, 2003 2:41 AM
To: Steve Hanna
Cc: Anders Rundgren; [email-masked]
Subject: Re: Certificate Policy Standardization

Steve Hanna wrote:
> Applications can use certificate policy OIDs to make
> trust decisions today. The application just needs to
> have a way for the user or administrator to configure
> the list of acceptable certificate policies (called
> the user-initial-policy-set in RFC 3280).

Which is as bad as the user or administrator installing trusted root CA 
certs. Or a browser vendor charging CAs for placing their root CA cert in 
the default installation. Or...

Again this boils down to policy OIDs just being another useless PKIX bloat 
extension.

Ciao, Michael.

Date: Tue, 25 Nov 2003 09:51:19 -0500
To: Richard Levitte - VMS Whacker <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

>
>
>michael> Again this boils down to policy OIDs just being another
>michael> useless PKIX bloat extension.
>
>Uhmm, I might be historically clueless here: are policy OIDs really a
>PKIX invention?
>
Policy OIDs are part of X.509, not a PKIX invention.  The complaint 
is just the usual carping about standards, with inaccurate 
attribution. In Michael's world view blame can be distributed 
universally, at least in the direction of others :-)

Steve

Date: Tue, 25 Nov 2003 09:43:43 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: <[email-masked]>
Sender: [email-masked]

At 17:56 -0800 11/24/03, todd glassey wrote:
>Charter or not Stephen - its something that is critically missing in all
>eBusiness processes. That being some uniform method of invoking the coverage
>of eSign acts and some method of specifying in the transaction receipt, what
>jurisdiction the specific act is done under.
>
>That you done want this as part of PKIX is also not relevant as to whether
>its needed, only to whether PKIX is allowed to focus on it.
>
>Todd :-)

Todd,

The relevant discussion for this list is whether the formulation of 
such policies, their publication, and assignment of OIDs is a PKIX 
topic.  The answer is NO to all three of these possible activities, 
in the PKIX context.

If you are convinced this is an important problem, take it to a forum 
when you can pursue it.

Steve

P.S.  I am totally unconvinced that we require a standard set of 
policies to be established by a standards organization like the IETF, 
ITU, ASMI, etc.  As others have noted, CAs are free to create their 
own and they usually do. If I were operating an EDI net of some sort 
I might create one for that context and operate a CA for the 
subscribers.  At most one needs to register OIDs to avoid collisions. 
But, reference to a CPS can be effected via out-of-band means, or via 
a proprietary extension; there are lots of ways people deal with this 
issue today.

Date: Tue, 25 Nov 2003 09:41:27 -0500
From: Steve Hanna <[email-masked]>
To: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
CC: Anders Rundgren <[email-masked]>, [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msD0C286071AFEC49362983560
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael Str�der wrote:
> Again this boils down to policy OIDs just being
> another useless PKIX bloat extension.

One man's bloat is another man's critical feature.

Some user communities don't care much about certificate
policy or have only one policy for their whole PKI.
They don't need policy OIDs. Other user communities
(especially government) want to support multiple
policies within a single PKI. For them, policy OIDs
are perfect.

I'm afraid that your perspective on PKI is too narrow.

Thanks,

Steve
--------------msD0C286071AFEC49362983560
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

--------------msD0C286071AFEC49362983560--

From: "Ing. Raffaello Galli" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: R: Re[2]: TSA certificate content
Date: Tue, 25 Nov 2003 14:27:45 +0100
Importance: Normal
Sender: [email-masked]

I->> As the specification actually, I also think that absence of keyUsage is
->> permissible.
->>
->> But I wonder why a certificate do not include keyUsage extension, though
->> the certificate declares extendedKeyUsage.
->> What kind of situation does it apply in?
->>
->> I have no idea about the reason to use only extendedKeyUsage extension
->> for a certificate without using keyUsage extension...
->>
->
->In RFC 3280 page 41 about extendedkeyUsage:
->
->   If the extension is present, then the certificate MUST only be used
->   for one of the purposes indicated.
->
->I understand this as "no need to set anything at all in keyUsage."

No I do not agree,  as I've explained in my previos mail according to the
RFC3161
the extendedkeyUsage (id-kp-timeStamping) MUST be the only one.
This doesn't  mean that the Key Usage should not be set.
In fact in RFC 3280 (page 42) regarding id-kp-timeStamping  says:
"Key usage bits may be consistent: digitalSignature and/or nonRepudiation"

Cheer
Raffaello

Reply-To: "todd glassey" <[email-masked]>
From: "todd glassey" <[email-masked]>
To: "todd glassey" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 17:56:14 -0800
Sender: [email-masked]

Charter or not Stephen - its something that is critically missing in all
eBusiness processes. That being some uniform method of invoking the coverage
of eSign acts and some method of specifying in the transaction receipt, what
jurisdiction the specific act is done under.

That you done want this as part of PKIX is also not relevant as to whether
its needed, only to whether PKIX is allowed to focus on it.

Todd :-)

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Monday, November 24, 2003 9:35 AM
Subject: Re: Certificate Policy Standardization

>
> At 8:23 -0800 11/24/03, todd glassey wrote:
> >----- Original Message -----
> >From: "Anders Rundgren" <[email-masked]>
> >To: <[email-masked]>
> >Sent: Monday, November 24, 2003 5:30 AM
> >Subject: Certificate Policy Standardization
> >
> >
> >>
> >>  Several persons have over the years claimed that applications
> >>  should select to trust (and recognize) certificates depending
> >>  on policy identifiers embedded in the certificates.
> >>
> >>  In order to get this to work, you "only" need to standardize
> >>  such identifiers.
> >
> >I tried to point this out several years ago and got slammed as it was not
> >part of PKIX's focus as to how the real-world was to use its wares. I
> >suggested several interaoperations OID Tables and one in particular for
> >indicating which particular electronic signature act any given
transaction
> >was supposewdly done under.
> >
> >Todd
>
> And this is still not part of the PKIX charter.
>
> Policies could be created on an industry sector basis, for example.
> The IETF could publish the resulting policies and assign OIDs, but
> PKIX is not a suitable forum for the development of such policies.
>
> Steve

Date: Tue, 25 Nov 2003 12:41:38 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Tue, 25 Nov 2003 11:50:00 +0100, Michael Str�der <[email-masked]> said:

michael> > as long as the user or
michael> > administrator knows what he/she is doing.
michael> 
michael> Well, the difference between theory and common practice...

*ahem* true...

michael> >  It's not much different
michael> > from, say, adding another public key to your PGP key ring annd
michael> > applying trust to it...  It can be done in a cluelessly with no
michael> > checks, or in a clued-in way with checks.
michael> 
michael> But the question raised here was what we will gain with
michael> certificate policy OIDs.

Granularity, and a resolution to the question "can this certificate be
used for this $10M transaction" (and other similar questions)...
After all, the problem that was "solved" with policy OIDs was the fact
that all certificates were assumed to be equal under one (unwritten?)
policy, correct?

So now, we have a problem with the solution and there are forces to go
back to a "one policy fits all" kind of thing?  I'm not sure how that
is better...  Of course, with Anders' observation that the common
thing is CA <=> Policy, it kind of makes sense.  However, that's the
current state of affairs, just as mesh PKIs aren't really supported by
quite a lot of software (I can name one that I know of :-/), and other
stuff like that.  Who says it's going to stay that way?

michael> > michael> Or a browser vendor charging CAs for placing their
michael> > michael> root CA cert in the default installation. Or...
michael> > 
michael> > That's a different story, and an action that generates such
michael> > feelings in me that I lack words to express them (not happy
michael> > feelings, I can tell you that).
michael> 
michael> Guess what would happen with certificate policy OIDs if
michael> widely deployed.

Well, how do you solve that?  If things are this bad (and it's not
something we know for sure, although guessing it is doesn't feel too
far-fetched), it will stay that way whatever is invented.  People will
always make short-cuts, and software producers will definitely keep
doing so to keep the fingers of their customers clean...  I see no way
out of that short of paying them a visit with a bat and slam some
sense into them.

(OK, I'm a cynic)

michael> > michael> Again this boils down to policy OIDs just being another
michael> > michael> useless PKIX bloat extension.
michael> > 
michael> > Uhmm, I might be historically clueless here: are policy
michael> > OIDs really a PKIX invention?
michael> 
michael> It doesn't really matter whether this extension was invented
michael> in X.509v3 or PKIX.

Point.  I asked merely out of intellectual curiosity.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Tue, 25 Nov 2003 12:00:44 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Re[2]: TSA certificate content
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 
> As the specification actually, I also think that absence of keyUsage is
> permissible.
> 
> But I wonder why a certificate do not include keyUsage extension, though
> the certificate declares extendedKeyUsage.
> What kind of situation does it apply in?
> 
> I have no idea about the reason to use only extendedKeyUsage extension
> for a certificate without using keyUsage extension...
> 

In RFC 3280 page 41 about extendedkeyUsage: 

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated. 

I understand this as "no need to set anything at all in keyUsage."  

Date: Tue, 25 Nov 2003 11:50:00 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Richard Levitte - VMS Whacker <[email-masked]>
Cc: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Richard Levitte - VMS Whacker wrote:
> In message <[email-masked]> on Tue, 25 Nov 2003 08:40:32 +0100, Michael Str�der <[email-masked]> said:
> 
> michael> Steve Hanna wrote:
> michael> > Applications can use certificate policy OIDs to make
> michael> > trust decisions today. The application just needs to
> michael> > have a way for the user or administrator to configure
> michael> > the list of acceptable certificate policies (called
> michael> > the user-initial-policy-set in RFC 3280).
> michael> 
> michael> Which is as bad as the user or administrator installing
> michael> trusted root CA certs.
> 
> I don't see why that's inherently bad,

It's not inherently bad.

> as long as the user or
> administrator knows what he/she is doing.

Well, the difference between theory and common practice...

>  It's not much different
> from, say, adding another public key to your PGP key ring annd
> applying trust to it...  It can be done in a cluelessly with no
> checks, or in a clued-in way with checks.

But the question raised here was what we will gain with
certificate policy OIDs.

> michael> Or a browser vendor charging CAs for placing their root CA
> michael> cert in the default installation. Or...
> 
> That's a different story, and an action that generates such feelings
> in me that I lack words to express them (not happy feelings, I can
> tell you that).

Guess what would happen with certificate policy OIDs if widely deployed.

> michael> Again this boils down to policy OIDs just being another
> michael> useless PKIX bloat extension.
> 
> Uhmm, I might be historically clueless here: are policy OIDs really a
> PKIX invention?

It doesn't really matter whether this extension was invented in X.509v3 or PKIX.

Ciao, Michael.

Date: Tue, 25 Nov 2003 11:39:57 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Tue, 25 Nov 2003 08:40:32 +0100, Michael Str�der <[email-masked]> said:

michael> 
michael> Steve Hanna wrote:
michael> > Applications can use certificate policy OIDs to make
michael> > trust decisions today. The application just needs to
michael> > have a way for the user or administrator to configure
michael> > the list of acceptable certificate policies (called
michael> > the user-initial-policy-set in RFC 3280).
michael> 
michael> Which is as bad as the user or administrator installing
michael> trusted root CA certs.

I don't see why that's inherently bad, as long as the user or
administrator knows what he/she is doing.  It's not much different
from, say, adding another public key to your PGP key ring annd
applying trust to it...  It can be done in a cluelessly with no
checks, or in a clued-in way with checks.

michael> Or a browser vendor charging CAs for placing their root CA
michael> cert in the default installation. Or...

That's a different story, and an action that generates such feelings
in me that I lack words to express them (not happy feelings, I can
tell you that).

michael> Again this boils down to policy OIDs just being another
michael> useless PKIX bloat extension.

Uhmm, I might be historically clueless here: are policy OIDs really a
PKIX invention?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Tue, 25 Nov 2003 18:20:50 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>
Subject: Re[2]: TSA certificate content
Cc: <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Sender: [email-masked]

Hi Peter,

As the specification actually, I also think that absence of keyUsage is
permissible.

But I wonder why a certificate do not include keyUsage extension, though
the certificate declares extendedKeyUsage.
What kind of situation does it apply in?

I have no idea about the reason to use only extendedKeyUsage extension
for a certificate without using keyUsage extension...

On Mon, 24 Nov 2003 21:40:56 -0500
"Santosh Chokhani" <[email-masked]> wrote:

> 
> Peter:
> 
> Based on a review of 3280 and 3161, I would say that absence of keyUsage
> extension is permissible.
> 
> 3161 requires extended key usage to be present as well as critical.  It also
> requires only one key purpose in the extension, that for time stamping.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Sylvester
> Sent: Monday, November 24, 2003 8:30 AM
> To: [email-masked]
> Subject: TSA certificate content
> 
> 
> 
> 
> I would like to hear some opinion about the setting
> of the extension keyUsage in a certificate for a
> 3161 TSA. 
> 
> The question is whether a certificate contain no
> keyUsage extension at all and only an extended
> key usage with the appropriate key purpose
> is conformant with 3161 and 3280. 
> 
> Peter 
> 
> 

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

From: "Ing. Raffaello Galli" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "'Peter Sylvester'" <[email-masked]>, <[email-masked]>
Subject: R: TSA certificate content
Date: Tue, 25 Nov 2003 09:54:29 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B5_01C3B33A.1E2A7580
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Peter,

According to rfc3161:

   2.3. Identification of the TSA

   The TSA MUST sign each time-stamp message with a key reserved
   specifically for that purpose.  A TSA MAY have distinct private keys,
   e.g., to accommodate different policies, different algorithms,
   different private key sizes or to increase the performance.  The
   corresponding certificate MUST contain only one instance of the
   extended key usage field extension as defined in [RFC2459] Section
   4.2.1.13 with KeyPurposeID having value:

   id-kp-timeStamping.  This extension MUST be critical.
.

According to  rfc3280:

4.2.1.13  Extended Key Usage
...........................
id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
   -- Binding the hash of an object to a time
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation

So according to the RFCs the TSA certificate

1)  MUST have only one instance  "extended key usage" extension with the
value
      id-kp-timeStamping  and this must be Critical.

2) The value of the extension "key usage" may be consistent.
     (i.e. digitalSignature e/o nonRepudiation   - Critical it is
recommended
      but not mandatory)

Regards

Raffaello

->-----Messaggio originale-----
->Da: [email-masked]
->[mailto:[email-masked]]Per conto di Santosh Chokhani
->Inviato: Tuesday, November 25, 2003 3:41 AM
->A: 'Peter Sylvester'; [email-masked]
->Oggetto: RE: TSA certificate content
->
->
->
->Peter:
->
->Based on a review of 3280 and 3161, I would say that absence of keyUsage
->extension is permissible.
->
->3161 requires extended key usage to be present as well as
->critical.  It also
->requires only one key purpose in the extension, that for time stamping.
->
->>-----Original Message-----
->>From: [email-masked]
->>[mailto:[email-masked]] On
->>Behalf Of Peter Sylvester
->>Sent: Monday, November 24, 2003 8:30 AM
->>To: [email-masked]
->>Subject: TSA certificate content
->>
->>
->>
->>
->>I would like to hear some opinion about the setting
->>of the extension keyUsage in a certificate for a
->>3161 TSA.
->>
->>The question is whether a certificate contain no
->>keyUsage extension at all and only an extended
->>key usage with the appropriate key purpose
->>is conformant with 3161 and 3280.
->>
->>Peter
->>

------=_NextPart_000_00B5_01C3B33A.1E2A7580
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<P><FONT size=3D2><FONT size=3D3>Peter,<BR><BR>According to=20
rfc3161:<BR></FONT><BR>&nbsp;&nbsp; 2.3. Identification of the=20
TSA<BR><BR>&nbsp;&nbsp; The TSA MUST sign each time-stamp message with a =
key=20
reserved<BR>&nbsp;&nbsp; specifically for that purpose.&nbsp; A TSA MAY =
have=20
distinct private keys,<BR>&nbsp;&nbsp; e.g., to accommodate different =
policies,=20
different algorithms,<BR>&nbsp;&nbsp; different private key sizes or to =
increase=20
the performance.&nbsp; The<BR>&nbsp;&nbsp; corresponding certificate =
MUST=20
contain only one instance of the<BR>&nbsp;&nbsp; extended key usage =
field=20
extension as defined in [RFC2459] Section<BR>&nbsp;&nbsp; 4.2.1.13 with=20
KeyPurposeID having value:<BR><BR>&nbsp;&nbsp; id-kp-timeStamping.&nbsp; =
This=20
extension MUST be critical.<BR>.<BR><BR><BR></FONT><FONT =
size=3D3>According to=20
&nbsp;rfc3280:<BR></FONT></P>
<P><FONT size=3D2>4.2.1.13&nbsp; Extended Key=20
Usage<BR>...........................<BR>id-kp-timeStamping&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-kp 8 }<BR>&nbsp;&nbsp; -- Binding the hash =
of an=20
object to a time<BR>&nbsp;&nbsp; -- Key usage bits that may be =
consistent:=20
digitalSignature<BR>&nbsp;&nbsp; -- and/or =
nonRepudiation<BR><BR></FONT><FONT=20
size=3D2><BR></FONT>So according to the RFCs the TSA certificate </P>
<P>1)&nbsp; MUST have&nbsp;only one instance&nbsp; "extended key usage"=20
extension with the=20
value&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;id-kp-timeStamping&nbs=
p; and=20
this must be Critical.</P>
<P><FONT size=3D2><FONT size=3D3>2)&nbsp;The value of the extension "key =
usage" may=20
be consistent.<BR>&nbsp;&nbsp; &nbsp; (i.e. digitalSignature e/o=20
nonRepudiation&nbsp;&nbsp; -&nbsp;Critical it is recommended=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but not mandatory)<BR><BR>Regards=20
</FONT></FONT></P>
<P><FONT size=3D2><FONT =
size=3D3>Raffaello</FONT><BR><BR>-&gt;-----Messaggio=20
originale-----<BR>-&gt;Da: =
[email-masked]<BR>-&gt;[</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>mailto:[email-masked]</FONT></A><FONT =
size=3D2>]Per conto di=20
Santosh Chokhani<BR>-&gt;Inviato: Tuesday, November 25, 2003 3:41 =
AM<BR>-&gt;A:=20
'Peter Sylvester'; [email-masked]<BR>-&gt;Oggetto: RE: TSA =
certificate=20
content<BR>-&gt;<BR>-&gt;<BR>-&gt;<BR>-&gt;Peter:<BR>-&gt;<BR>-&gt;Based =
on a=20
review of 3280 and 3161, I would say that absence of =
keyUsage<BR>-&gt;extension=20
is permissible.<BR>-&gt;<BR>-&gt;3161 requires extended key usage to be =
present=20
as well as<BR>-&gt;critical.&nbsp; It also<BR>-&gt;requires only one key =
purpose=20
in the extension, that for time =
stamping.<BR>-&gt;<BR>-&gt;&gt;-----Original=20
Message-----<BR>-&gt;&gt;From:=20
[email-masked]<BR>-&gt;&gt;[</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>mailto:[email-masked]</FONT></A><FONT size=3D2>]=20
On<BR>-&gt;&gt;Behalf Of Peter Sylvester<BR>-&gt;&gt;Sent: Monday, =
November 24,=20
2003 8:30 AM<BR>-&gt;&gt;To: [email-masked]<BR>-&gt;&gt;Subject: TSA=20
certificate=20
content<BR>-&gt;&gt;<BR>-&gt;&gt;<BR>-&gt;&gt;<BR>-&gt;&gt;<BR>-&gt;&gt;I=
 would=20
like to hear some opinion about the setting<BR>-&gt;&gt;of the extension =

keyUsage in a certificate for a<BR>-&gt;&gt;3161=20
TSA.<BR>-&gt;&gt;<BR>-&gt;&gt;The question is whether a certificate =
contain=20
no<BR>-&gt;&gt;keyUsage extension at all and only an =
extended<BR>-&gt;&gt;key=20
usage with the appropriate key purpose<BR>-&gt;&gt;is conformant with =
3161 and=20
3280.<BR>-&gt;&gt;<BR>-&gt;&gt;Peter<BR>-&gt;&gt;<BR></P></FONT></BODY></=
HTML>

------=_NextPart_000_00B5_01C3B33A.1E2A7580--

Date: Tue, 25 Nov 2003 09:11:18 +0100
From: Joseph Doekbrijder <[email-masked]>
Organization: SwissSign AG
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Hi Anders

Have a look at http://csp-forum.ch
We are in Switzerland (with partial support of the Swiss government) 
working on a system where indeed trust is based on a certificate level 
or "quality". This work is based on RFC 2527 and soon needs to be 
adapted/changed to RFC 3647   :-)

The presentation 
http://csp-forum.ch/pdf/PKI%20Forum%20meeting%2016-01-03.pdf shows a 
good overview of the idea

ps. the web site is not up-to-date   :-)

Looking forward to your (or anyone's) feedback

Anders Rundgren wrote:

>Several persons have over the years claimed that applications
>should select to trust (and recognize) certificates depending
>on policy identifiers embedded in the certificates.
>
>In order to get this to work, you "only" need to standardize
>such identifiers.   My question is bluntly: Is there any such
>work going on on a global scale?  And if so, why have this
>information not reached the PKIX-list?
>
>Anders
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
L�wenstrasse 1, CH-8001 Z�rich
Tel: +41 43 344 88 11 Mobil: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

Date: Tue, 25 Nov 2003 08:40:32 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Steve Hanna <[email-masked]>
Cc: Anders Rundgren <[email-masked]>, [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

Steve Hanna wrote:
> Applications can use certificate policy OIDs to make
> trust decisions today. The application just needs to
> have a way for the user or administrator to configure
> the list of acceptable certificate policies (called
> the user-initial-policy-set in RFC 3280).

Which is as bad as the user or administrator installing trusted root CA 
certs. Or a browser vendor charging CAs for placing their root CA cert in 
the default installation. Or...

Again this boils down to policy OIDs just being another useless PKIX bloat 
extension.

Ciao, Michael.

From: "Santosh Chokhani" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>
Subject: RE: TSA certificate content
Date: Mon, 24 Nov 2003 21:40:56 -0500
Importance: Normal
Sender: [email-masked]

Peter:

Based on a review of 3280 and 3161, I would say that absence of keyUsage
extension is permissible.

3161 requires extended key usage to be present as well as critical.  It also
requires only one key purpose in the extension, that for time stamping.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Sylvester
Sent: Monday, November 24, 2003 8:30 AM
To: [email-masked]
Subject: TSA certificate content

I would like to hear some opinion about the setting
of the extension keyUsage in a certificate for a
3161 TSA. 

The question is whether a certificate contain no
keyUsage extension at all and only an extended
key usage with the appropriate key purpose
is conformant with 3161 and 3280. 

Peter 

From: "Anders Rundgren" <[email-masked]>
To: "Hans Nilsson" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 23:42:47 +0100
Sender: [email-masked]

>Besides these, I do not think we ever will se any such CP OIDs. Every CA
>usually wants to state its own highlights and limitations. 

>Sorry. Go fight some other windmill :-)

But dear Hans, you are just confirming what I have tried to say
a zillions times before: To build global-scale PKI using CP OIDs
as application trust selection mechanism is not a good idea. 

I do though see a "de-facto" standard among commercial CAs
and that is simply making:

              CA <==> Policy

This scheme has a number of advantages over using the
RFC3280 policy stuff, including:

- It works on any scale

- It can be explained to just about anybody ranging from an
  ASN.1 guru to a lawyer.

That this breaks away from PKI rule #1, i.e.  "everything must be
utterly complicated otherwise it cannot be secure", is at least
something I can live with.

Anders

----- Original Message ----- 
From: "Hans Nilsson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 24, 2003 20:39
Subject: RE: Certificate Policy Standardization

Anders,

The only "standardized" and "public" CP OID that exists are the two ones
defined by ETSI for Qualified Certificates:

"The identifiers for the qualified certificate policies specified in the
present document are:

a) QCP public + SSCD: a certificate policy for qualified certificates issued
to the public, requiring use of secure signature-creation devices
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public-with-sscd (1)

b) QCP public: a certificate policy for qualified certificates issued to the
public
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public (2)"

Besides these, I do not think we ever will se any such CP OIDs. Every CA
usually wants to state its own highlights and limitations. 

Sorry. Go fight some other windmill :-)

Hans

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Monday, November 24, 2003 7:10 PM
> To: [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> >I am unaware of any such standardization.  Some organizations have
> >developed and published their own CPs.  I find that recent CPs have
> >copied liberally from the earlier ones.
> 
> To cut and paste text from various sources seems like a rather
> different activity than defining common CPs and associated OIDs.
> 
> /a

Date: Mon, 24 Nov 2003 17:20:05 -0500
To: "Terry Hayes" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

At 12:08 -0800 11/24/03, Terry Hayes wrote:
>Stephen Kent wrote on 11/24/2003, 9:35 AM:
>>  ...
>>  And this is still not part of the PKIX charter.
>>
>>  Policies could be created on an industry sector basis, for example.
>>  The IETF could publish the resulting policies and assign OIDs, but
>>  PKIX is not a suitable forum for the development of such policies.
>>
>
>I believe that there are at least three "industry sectors" where the 
>IETF would be an appropriate forum for developing certificate 
>policies.  They are SSL/TLS host (server) certificates, email 
>(S/MIME used for email) certificates and IPSEC certificates. All 
>three of these areas have protocols defined by the IETF that uses 
>certificates to establish identities.

these are protocols, not industry sectors. One might make an argument 
for protocol-based policies as well, but it would be a different 
argument.

>In my opinion, the IETF should define a CP and corresponding OID for 
>each of these areas.  The policy would need to be fairly general in 
>many areas (such as protection of key material).  However, the 
>policy should be spell out certificate content and authentication 
>procedures that should be followed to allow most applications to 
>accept the certificate.  For example, for TLS host certificates, the 
>CA must do a reasonable check that the DNS in the certificate 
>belongs to the one requesting the certificate.

This is not going to be done in PKIX. I leave it to Russ to indicate 
whether he thinks this might be done in a follow on WG, or whether it 
is the province of the WGs for the protocols you mention. Note that 
with the advent of 3280, we decided to let protocols that are PKI 
clients define extended key usage options for themselves. If one 
argued for protocol-specific policies, then the same reasoning might 
apply here too.

>It may not be part of the PKIX charter to define these policies and 
>OIDs, but I think it is within the scope of the TLS, S/MIME and 
>IPSEC working groups to do so.

Yep, they might, if they agree with the concept that this is a 
protocol-specific policy matter, vs. an industry sector matter, etc.

Steve

Content-class: urn:content-classes:message
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Mon, 24 Nov 2003 12:25:00 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I suspect that many server implementations don't have appropriate
handling of critically marked extensions, even for known once like the
nonce due to the way the RFC is written.

That's not to say that if I am right their behavior would be correct,
but this is something we all experienced with the early days of X509
support.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Marc Branchaud
Sent: Monday, November 24, 2003 9:13 AM
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

Ryan M. Hurst wrote:
> You are right, should not does mean not recomended however the likley 
> impact is that clients that do this will not be able to interoperate 
> with the existing servers out there.

They'll only be uninteroperable with servers that don't support nonces, 
which is exactly what we want.

The client would in any case be free to resend the query without the 
nonce, and the client could retain the fact that the server doesn't 
support nonces.

		M.

Date: Mon, 24 Nov 2003 12:08:46 -0800
From: "Terry Hayes" <[email-masked]>
Subject: Re: Certificate Policy Standardization
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Organization: AOL
Sender: [email-masked]

Stephen Kent wrote on 11/24/2003, 9:35 AM:
> ...
> And this is still not part of the PKIX charter. 
> 
> Policies could be created on an industry sector basis, for example. 
> The IETF could publish the resulting policies and assign OIDs, but 
> PKIX is not a suitable forum for the development of such policies. 
> 

I believe that there are at least three "industry sectors" where the IETF would be an appropriate forum for developing certificate policies.  They are SSL/TLS host (server) certificates, email (S/MIME used for email) certificates and IPSEC certificates. All three of these areas have protocols defined by the IETF that uses certificates to establish identities.

In my opinion, the IETF should define a CP and corresponding OID for each of these areas.  The policy would need to be fairly general in many areas (such as protection of key material).  However, the policy should be spell out certificate content and authentication procedures that should be followed to allow most applications to accept the certificate.  For example, for TLS host certificates, the CA must do a reasonable check that the DNS in the certificate belongs to the one requesting the certificate.

It may not be part of the PKIX charter to define these policies and OIDs, but I think it is within the scope of the TLS, S/MIME and IPSEC working groups to do so.

Terry Hayes

From: "Hans Nilsson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 20:39:34 +0100
Sender: [email-masked]

Anders,

The only "standardized" and "public" CP OID that exists are the two ones
defined by ETSI for Qualified Certificates:

"The identifiers for the qualified certificate policies specified in the
present document are:

a) QCP public + SSCD: a certificate policy for qualified certificates issued
to the public, requiring use of secure signature-creation devices
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public-with-sscd (1)

b) QCP public: a certificate policy for qualified certificates issued to the
public
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public (2)"

Besides these, I do not think we ever will se any such CP OIDs. Every CA
usually wants to state its own highlights and limitations. 

Sorry. Go fight some other windmill :-)

Hans

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anders Rundgren
> Sent: Monday, November 24, 2003 7:10 PM
> To: [email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> >I am unaware of any such standardization.  Some organizations have
> >developed and published their own CPs.  I find that recent CPs have
> >copied liberally from the earlier ones.
> 
> To cut and paste text from various sources seems like a rather
> different activity than defining common CPs and associated OIDs.
> 
> /a

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: WG last call re draft-pkix-acpolicies-extn-03.txt
Date: Mon, 24 Nov 2003 11:28:37 -0800
Importance: Normal
Sender: [email-masked]

Denis,

I just found a minor issue.

In the ASN.1 module you are referencing [PROFILE] rather than [RFC3280].

jim

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 19:10:19 +0100
Sender: [email-masked]

>I am unaware of any such standardization.  Some organizations have 
>developed and published their own CPs.  I find that recent CPs have
>copied liberally from the earlier ones.

To cut and paste text from various sources seems like a rather
different activity than defining common CPs and associated OIDs.

/a

Date: Mon, 24 Nov 2003 12:35:25 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 8:23 -0800 11/24/03, todd glassey wrote:
>----- Original Message -----
>From: "Anders Rundgren" <[email-masked]>
>To: <[email-masked]>
>Sent: Monday, November 24, 2003 5:30 AM
>Subject: Certificate Policy Standardization
>
>
>>
>>  Several persons have over the years claimed that applications
>>  should select to trust (and recognize) certificates depending
>>  on policy identifiers embedded in the certificates.
>>
>>  In order to get this to work, you "only" need to standardize
>>  such identifiers.
>
>I tried to point this out several years ago and got slammed as it was not
>part of PKIX's focus as to how the real-world was to use its wares. I
>suggested several interaoperations OID Tables and one in particular for
>indicating which particular electronic signature act any given transaction
>was supposewdly done under.
>
>Todd

And this is still not part of the PKIX charter.

Policies could be created on an industry sector basis, for example. 
The IETF could publish the resulting policies and assign OIDs, but 
PKIX is not a suitable forum for the development of such policies.

Steve

Date: Mon, 24 Nov 2003 09:12:33 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Ryan M. Hurst wrote:
> You are right, should not does mean not recomended however the likley 
> impact is that clients that do this will not be able to interoperate 
> with the existing servers out there.

They'll only be uninteroperable with servers that don't support nonces, 
which is exactly what we want.

The client would in any case be free to resend the query without the 
nonce, and the client could retain the fact that the server doesn't 
support nonces.

		M.

--------------ms050105060906050608070004
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

--------------ms050105060906050608070004--

Date: Mon, 24 Nov 2003 11:47:25 -0500
From: Steve Hanna <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Applications can use certificate policy OIDs to make
trust decisions today. The application just needs to
have a way for the user or administrator to configure
the list of acceptable certificate policies (called
the user-initial-policy-set in RFC 3280).

There is something to be said for attempting to
develop standard certificate policies and corresponding
OIDs. There may be some efforts underway to do so, but
I'm not an expert in this area. However, applications
and users don't need to wait for such standards to arrive
in order to use certificate policy OIDs in making trust
decisions. Of course, there's no need to do this if all
the CAs in your PKI only support one certificate policy!

Thanks,

Steve

Anders Rundgren wrote:
> 
> Several persons have over the years claimed that applications
> should select to trust (and recognize) certificates depending
> on policy identifiers embedded in the certificates.
> 
> In order to get this to work, you "only" need to standardize
> such identifiers.   My question is bluntly: Is there any such
> work going on on a global scale?  And if so, why have this
> information not reached the PKIX-list?
> 
> Anders
--------------msD584A57CC3BDF3C041F7008A
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

--------------msD584A57CC3BDF3C041F7008A--

Reply-To: "todd glassey" <[email-masked]>
From: "todd glassey" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 08:23:16 -0800
Sender: [email-masked]

----- Original Message -----
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 24, 2003 5:30 AM
Subject: Certificate Policy Standardization

>
> Several persons have over the years claimed that applications
> should select to trust (and recognize) certificates depending
> on policy identifiers embedded in the certificates.
>
> In order to get this to work, you "only" need to standardize
> such identifiers.

I tried to point this out several years ago and got slammed as it was not
part of PKIX's focus as to how the real-world was to use its wares. I
suggested several interaoperations OID Tables and one in particular for
indicating which particular electronic signature act any given transaction
was supposewdly done under.

Todd

>  My question is bluntly: Is there any such
> work going on on a global scale?  And if so, why have this
> information not reached the PKIX-list?
>
> Anders

Date: Mon, 24 Nov 2003 10:56:09 -0500
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

I am unaware of any such standardization.  Some organizations have 
developed and published their own CPs.  I find that recend CPs have copied 
liberally from the earlier ones.

Russ

At 02:30 PM 11/24/2003 +0100, Anders Rundgren wrote:

>Several persons have over the years claimed that applications
>should select to trust (and recognize) certificates depending
>on policy identifiers embedded in the certificates.
>
>In order to get this to work, you "only" need to standardize
>such identifiers.   My question is bluntly: Is there any such
>work going on on a global scale?  And if so, why have this
>information not reached the PKIX-list?
>
>Anders

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 14:30:13 +0100
Sender: [email-masked]

Several persons have over the years claimed that applications
should select to trust (and recognize) certificates depending
on policy identifiers embedded in the certificates.

In order to get this to work, you "only" need to standardize
such identifiers.   My question is bluntly: Is there any such
work going on on a global scale?  And if so, why have this
information not reached the PKIX-list?

Anders

Date: Mon, 24 Nov 2003 14:30:05 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: TSA certificate content
Sender: [email-masked]

I would like to hear some opinion about the setting
of the extension keyUsage in a certificate for a
3161 TSA. 

The question is whether a certificate contain no
keyUsage extension at all and only an extended
key usage with the appropriate key purpose
is conformant with 3161 and 3280. 

Peter 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Fri, 21 Nov 2003 22:39:23 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_008D_01C3B07F.74650AE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Russ:

I also think Marc's proposal may be the best way forward given the way the
RFC is written.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Marc Branchaud
Sent: Friday, November 21, 2003 5:41 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

Russ Housley wrote:
>
> Section 4.1.2  of RFC 2560 says:
>
>    Support for any specific extension is OPTIONAL. The critical flag
>    SHOULD NOT be set for any of them.

I think that allowing critical nonces in requests is perfectly
compatible with that SHOULD NOT statement.

RFC2119 sez:

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.

I think that we have a valid reason to use the critical flag here.

		M.

------=_NextPart_000_008D_01C3B07F.74650AE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_008D_01C3B07F.74650AE0--

Content-class: urn:content-classes:message
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Fri, 21 Nov 2003 18:55:50 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B0A4.54BCB1A5"

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

You are right, should not does mean not recomended however the likley =
impact is that clients that do this will not be able to interoperate =
with the existing servers out there.
=20
Maybe we should do a straw pole to determin what servers will do if they =
get the nonce marked critical.
=20
Ryan

________________________________

From: [email-masked] on behalf of Marc Branchaud
Sent: Fri 11/21/2003 2:41 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

Russ Housley wrote:
>
> Section 4.1.2  of RFC 2560 says:
>
>    Support for any specific extension is OPTIONAL. The critical flag
>    SHOULD NOT be set for any of them.

I think that allowing critical nonces in requests is perfectly
compatible with that SHOULD NOT statement.

RFC2119 sez:

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.

I think that we have a valid reason to use the critical flag here.

                M.

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7097.0">=0A=
<TITLE>Re: OCSPv1 and nonces (RE: draft meeting minutes)</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText78044 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>You are =
right, should not =0A=
does mean not recomended however the likley impact is that clients that =
do this =0A=
will not be able to interoperate with the existing servers out =0A=
there.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Maybe we should do a straw =
pole to determin =0A=
what servers will do if they get the nonce marked critical.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Fri 11/21/2003 2:41 PM<BR><B>To:</B> Russ =0A=
Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> Re: OCSPv1 =
and nonces =0A=
(RE: draft meeting minutes)<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Russ Housley wrote:<BR>&gt;<BR>&gt; Section =
4.1.2&nbsp; of RFC =0A=
2560 says:<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp; Support for any specific =
extension =0A=
is OPTIONAL. The critical flag<BR>&gt;&nbsp;&nbsp;&nbsp; SHOULD NOT be =
set for =0A=
any of them.<BR><BR>I think that allowing critical nonces in requests is =0A=
perfectly<BR>compatible with that SHOULD NOT statement.<BR><BR>RFC2119 =0A=
sez:<BR><BR>4. SHOULD NOT&nbsp;&nbsp; This phrase, or the phrase "NOT =0A=
RECOMMENDED" mean that<BR>&nbsp;&nbsp;&nbsp; there may exist valid =
reasons in =0A=
particular circumstances when the<BR>&nbsp;&nbsp;&nbsp; particular =
behavior is =0A=
acceptable or even useful, but the full<BR>&nbsp;&nbsp;&nbsp; =
implications =0A=
should be understood and the case carefully =
weighed<BR>&nbsp;&nbsp;&nbsp; before =0A=
implementing any behavior described with this label.<BR><BR>I think that =
we have =0A=
a valid reason to use the critical flag =0A=
here.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M.<BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B0A4.54BCB1A5--

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

Date: Fri, 21 Nov 2003 18:01:10 -0500
To: Denis Pinkas <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: WG last call re draft-pkix-acpolicies-extn-03.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

These two OIDs have been assigned.

Russ

At 04:37 PM 11/21/2003 +0100, Denis Pinkas wrote:
>     Russ, as the custodian of the PKIX OID, would you assign these two new
>     OIDs to acps and acunotice ?
>
>     id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
>     id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }

Date: Fri, 21 Nov 2003 14:41:00 -0800
From: Marc Branchaud <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Russ Housley wrote:
> 
> Section 4.1.2  of RFC 2560 says:
> 
>    Support for any specific extension is OPTIONAL. The critical flag
>    SHOULD NOT be set for any of them.

I think that allowing critical nonces in requests is perfectly 
compatible with that SHOULD NOT statement.

RFC2119 sez:

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.

I think that we have a valid reason to use the critical flag here.

		M.

--------------ms010202070803040302080102
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

--------------ms010202070803040302080102--

Date: Fri, 21 Nov 2003 17:31:08 -0500
To: Marc Branchaud <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes) 
Sender: [email-masked]

Marc:

I considered this approach too.  And right now, it may be the best way 
forward, but it does still have an impact on the specification.

Section 4.1.2  of RFC 2560 says:

    Support for any specific extension is OPTIONAL. The critical flag
    SHOULD NOT be set for any of them.

Russ

At 10:43 AM 11/21/2003 -0800, Marc Branchaud wrote:

>It seems to me that we could simply allow clients to make the nonce 
>extension critical.
>
>
>If the client makes nonce critical, it is essentially telling the server 
>that it will not accept a nonceless (cached) response.
>
>
>OTOH, if the client is willing to accept nonceless responses, it simply 
>makes the request's nonce extension non-critical.
>
>
>Responders that don't support nonces (e.g. caching or pre-generating 
>responders) have to return an error (internalError?) if the request has a 
>critical nonce extension.
>
>
>This approach doesn't add any new MUSTs or SHOULDs.  It just gives clients 
>the ability to ensure that their local policies are followed.
>
>
>                 M.
>
>
> >
>List-ID: <ietf-pkix.imc.org>
>List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
>X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on woodstock
>X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.60
>X-Spam-Level:
>
><file://c:\program files\qualcomm\eudora\attach\Re OCSPv1 and nonces (RE 
>draf.ems <0265.0002>>Re OCSPv1 and nonces (RE draf.ems

Content-class: urn:content-classes:message
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Fri, 21 Nov 2003 13:59:03 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I agree this seems like a simple approach however the OCSP RFC
(http://ietf.org/rfc/rfc2560.txt?number=2560 ) states that extensions
SHOULD NOT be critical; the concern here is that using this scheme to
communicate this policy would be a violation of that statement and make
folks incompatible.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Marc Branchaud
Sent: Friday, November 21, 2003 11:35 AM
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

Marc Branchaud wrote:
> 
> OTOH, if the client is willing to accept nonceless responses, it
simply 
> makes the request's nonce extension non-critical.

I also should've explicitly pointed out that it would be OK for a 
caching server to return a nonceless response in this case (i.e. to a 
request with a non-critical nonce).

		M.

Date: Fri, 21 Nov 2003 11:35:09 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Marc Branchaud wrote:
> 
> OTOH, if the client is willing to accept nonceless responses, it simply 
> makes the request's nonce extension non-critical.

I also should've explicitly pointed out that it would be OK for a 
caching server to return a nonceless response in this case (i.e. to a 
request with a non-critical nonce).

		M.

--------------ms090800080805040505010609
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

--------------ms090800080805040505010609--

Date: Fri, 21 Nov 2003 10:43:33 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

It seems to me that we could simply allow clients to make the nonce 
extension critical.

If the client makes nonce critical, it is essentially telling the server 
that it will not accept a nonceless (cached) response.

OTOH, if the client is willing to accept nonceless responses, it simply 
makes the request's nonce extension non-critical.

Responders that don't support nonces (e.g. caching or pre-generating 
responders) have to return an error (internalError?) if the request has 
a critical nonce extension.

This approach doesn't add any new MUSTs or SHOULDs.  It just gives 
clients the ability to ensure that their local policies are followed.

		M.

--------------ms070407050708060301040609
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

--------------ms070407050708060301040609--

Date: Fri, 21 Nov 2003 11:24:31 -0500 (EST)
From: Dave Engberg <[email-masked]>
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

Ok, we can accept that adding new extension declarations to v1 is 
out of scope.

Adding new mandatory rejection requirements (MUST) at the client and 
server based on the non-critical nonce extension does, however, prevent 
any willing v1-compatible clients and servers from choosing other security 
policies (e.g. based on other extensions) before v2.

Could we just change the new language from MUST to SHOULD for the client 
and the server?  This allows you to convey your intended semantics, but  
doesn't prevent the exploration of alternate security policies by willing 
client/server pairs before v2-final ...

Basically:  "Clients who send a nonce to a server and receive a response 
without a nonce SHOULD reject that response.  Servers who receive a 
request with a nonce who are unwilling or unable to supply a response with 
a nonce SHOULD return an 'unauthorized' error code."  (or somesuch)

Michael Myers wrote:
> Earlier today Steve wrote:  "I believe Russ's statement sets the
> parameters for how we clarify this issue within the bounds of
> OCSP v1."  Thus we need to determine, in part and if possible,
> what a v1-based caching server MUST send back to a nonced
> request using only the ASN.1 syntax defined by RFC 2560 as
> written.  Your proposed nonceUnsupported, while a candidate for
> v2 consideration, is clearly not within that v1 scope.

Date: Fri, 21 Nov 2003 16:37:33 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: WG last call re draft-pkix-acpolicies-extn-03.txt
Sender: [email-masked]

Jim,

Thank you for your very valuable comments.

A updated document is now available on the server :
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-04.txt

You will find hereafter a disposition of your comments.

The document should now be ready for the IESG last call.

Denis
Lead editor of draft-pkix-acpolicies-extn

Note for Russ: two new OIDs will need to be assigned.

=========================================================================

Gentlemen,

No judgement on good or badness of concept however the following present
implementation issues:

1.  Section 2.3 says that this document defines two policies which are
SIMILAR to those for public keys and then appears to use the save value.
Is this intended and if so then the text should be cleaned up.

The text has been fixed in the following way

     The policy qualifiers are similar but indeed different since they
     relate to an Attribute Certificate instead of a Public Key Certificate.
     To this respect two new OIDs will be needed in the id-qt arc and the
     updated document has been using two next one available in that category.

     Russ, as the custodian of the PKIX OID, would you assign these two new
     OIDs to acps and acunotice ?

     id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
     id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }

2.  What is the correct behavior if the extension is non-critical, the
extension is recognized, but none of the policy identifiers are recognized?

The following sentence has been added:

"If none of the AC policy identifiers is adequate for the application,
then the AC MUST be rejected."

ASN Module:

1.  Need to uncomment the imports statement.
Done

2.  need to add a semi-colon following the import of PolicyQualifiedId
OK

3.  PolicyQualifiedId needs to be imported form PKIXImplicit88.
It is defined both in PKIXExplicit88 and in PKIXImplicit88.

4.  id-pkix needs to be imported.
id-pe is now directly imported instead.

5.  ac-policies does needs to have "SYNTAX" and "IDENTIFIED BY" changed
as this is not correct 1988 syntax.
Done

6.  EXTENSION is not an identified type.
Done

7.  ac-policiesSyntax should start with an upper case letter as it is a type.
Done

8.  acPolicyId should start with an upper case letter as it is a type.
Done

   ... and many thanks for these comments.

In addition:

1 - The introduction has been changed to state:

The purpose of this document is to define an AC policies extension
able to explicitly state the AC policies that apply to a given AC,
but not the AC policies themselves"

2 - id-pe-ac-policies has been changed into id-pe-acPolicies

3 - The name of the ASN.1 module is now :
AcPolicies instead of PKIXac-policies

Jim

 > Gentlemen,
 >
 > No judgement on good or badness of concept however the following present
 > implementation issues:
 >
 > 1.  Section 2.3 says that this document defines two policies which are
 > SIMILAR to those for public keys and then appears to use the save value.
 > Is this intended and if so then the text should be cleaned up.
 >
 > 2.  What is the correct behavior if the extension is non-criticial, the
 > extension is recognized, but none of the policy identifiers are
 > recognized?
 >
 >
 >
 > ASN Module:
 >
 > 1.  Need to uncomment the imports statement
 >
 > 2.  need to add a semi-colon following the import of PolicyQualifiedId
 >
 > 3.  PolicyQualifiedId needs to be imported form PKIXImplicit88.
 >
 > 4.  id-pkix needs to be imported.
 >
 > 5.  ac-policies does needs to have "SYNTAX" and "IDENTIFIED BY" changed
 > as this is not correct 1988 syntax.
 >
 > 6.  EXTENSION is not an identified type.
 >
 > 7.  ac-policiesSyntax should start with an upper case letter as it is a
 > type.
 >
 > 8.  acPolicyId should start with an upper case letter as it is a type.
 >
 >
 > Jim

Date: 21 Nov 2003 11:15:50 -0000
From: "Florian Oelmaier" <[email-masked]>
To: [email-masked]
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

> I'm not surprised at your result.  Server-unilateral nonces are
> arguably consistent with standing 2560 syntax. However, this
> practice is not identified in the standard.  

/agree. Please note that if you dont like that, you have to clarfiy that, too! But as I stated in a former message, I would prefer an explicit extension as proposed by David or Tom.

But my comment regarding extensions was not targeted towards server-generated nonces. While OpenValidation.org uses server-generated nonces, most (98%+) requests we get contain nonces. Please mind: this does not mean that the client would not accept a non-nonced answer, as most clients out there do not know if openvalidation.org does caching or not. 

In my comment I was speaking about another extension (a private extension used by OpenValidation.org to deliver additional information to the clients). This is ongoing work, the idea is to deliver additional background information about the CA that can be presented to the user.

In the end I just wanted to stress the fact that adding a new responseExtension in a separate RfC does not necessarily mean we need to increment the OCSP-version number. But I think we all agree on that.

> More importantly,
> is it not responsive to client-driven prevention of replay
> attacks.

I think it is. As the responder never signs a response without nonce, it is semantically the same as a "NonceSupported=true" Extension. This method  reliably protects clients sending "nonced" requests but accepting "non-nonced" responses.

But either way: as stated above, I would prefer the proposal of Tom or David.  So no need to discuss the server-generated nonce proposal any further - at least not from my side.

> As to the likelihood of clarifying 2560 as it goes from Proposed
> to Draft with the guidance provided us by our Area Director, see
> RFC 2026.  The "MUST reject" clarification is amply supported by
> the breakage poll.
> 
> If you disagree with Russ's guidance, take it up with Steve or
> Russ.

I think both follow the discussion here. I am here to give my point of view - at the end of the day it is not my decision what to put into the standard. And as for the poll I agree with several others here that if you would ask now, clearly worded and with all implications on the table, the result may be different. 

If the proposed change really goes through I will add an option to my client where the users can decide between three settings:

#1 standard compliance with normal security (works with all responders)

[Technically: will use requests without nonce ]

#2 standard compliance with high security (does not work with all responders)

[Technically: will use requests with nonce and will not accept responses without nonce]

#3 high security with some responders/normal security with most (works with all responders and improves security with some. While technically 100% compatible this is not compliant to the RfC!)

[Technically: will use requests with nonce but will accept responses without nonce. This is the former default behaviour of my client but as it will not be standard compliant anymore, I will warn the user explicitly that he leaves the holy ground with that decision. 
Additionally I have to introduce a second round-trip without nonce if I get an error message (as I may have got this error message due to missing nonce support by a caching responder). But I think most caching responders will include an "old version compatibility" mode and simply send back a non-nonced response to a nonced request. This is arguably consistent even with the changed RfC as extension processing is optional.]

I hope this clarifies why I am so unhappy with the outlined "decision". But I have not yet given up hope that I can change #3 to something like Toms extension proposal (NonceSupported):

#3 high security with new responders (normal security for all older responders, high security for all responders compliant to RfCxxxx)

[Technically: requests with nonce, will accept responses without nonce but will NOT accept responses without nonce if NonceSupported=True extension is set]

or Davids proposal (NonceUnsupported):
 
#3 high security with fallback (works with all responders except older caching responders)

[Technically: requests with nonce, will accept responses without nonce only if NonceUnsupported extension is present]

While also solving the problem, both alternatives are technically superior, easier to understand and more straightforward to implement. But this has been laid out several times now, maybe its time to let the matter rest here  and see what the market will do. 

-- 
Florian Oelmaier
SyTrust

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Thu, 20 Nov 2003 12:29:40 -0800
Importance: Normal
Sender: [email-masked]

Florian,

I'm not surprised at your result.  Server-unilateral nonces are
arguably consistent with standing 2560 syntax. However, this
practice is not identified in the standard.  More importantly,
is it not responsive to client-driven prevention of replay
attacks.

As to the likelihood of clarifying 2560 as it goes from Proposed
to Draft with the guidance provided us by our Area Director, see
RFC 2026.  The "MUST reject" clarification is amply supported by
the breakage poll.

If you disagree with Russ's guidance, take it up with Steve or
Russ.

Mike

Date: 20 Nov 2003 18:20:30 -0000
From: "Florian Oelmaier" <[email-masked]>
To: [email-masked]
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

> The version number will be updated since legacy clients that are
> merrily going along parsing against v == 0 will very likely
> choke when they see bits on the wire they weren't expecting.

Seeing that the alternative proposal is a "responseExtension", clients will NOT choke. OpenValidation.org adds such an extension to every OCSP-Response for more than 6 months now. During this time we had thousands of requests sent by more than 45 clients (http://www.openvalidation.org/en/kontakt/ocsp_stats.html#browrep). 

The extenstion system in OCSP works and is fully compatible. No client will "choke". 

If you push the MUST reject "solution" through, I expect it to be the other way round: you may change the spec, but a lot of clients and servers will simply not adhere to it, as it is not compatible to some use-cases out there.

> Meanwhile, 2560 is going from Proposed to Draft.  We are allowed
> to and already have performed minor amendments.  The "MUST
> reject" clarification will be another.

Seeing the text size it will be a "minor" amendment, seeing the implications it is a HUGE change.

As this will change the specification very significantly, I wonder if the IESG will recommend that the revision be treated as a new document, reentering the standards track at the beginning.

-- 
Florian Oelmaier
SyTrust

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Thu, 20 Nov 2003 07:14:14 -0800
Importance: Normal
Sender: [email-masked]

The version number will be updated since legacy clients that are
merrily going along parsing against v == 0 will very likely
choke when they see bits on the wire they weren't expecting.
One hopes today's clients will are today sufficiently robust in
their implementation, e.g.:

if( buf->v == 0 ) proceed( buf ) else fail( BADVERSION );

such that, upon receipt of a value for v other than 0 (i.e. v1),
they will fail( ) with grace rather than proceed( ) in good
faith and choke.

Given a version number roll, we would be remiss if we didn't
also take the time to consider other v2 issues unrelated to the
use of nonces.  This is all going to take some time.

Further, we're nowhere near ready to recommend to Steve and Tim
a technical resolution.  We haven't fully discussed all possible
options.  Among these is the option of including some type of
value in a responder's certificate that enables a priori client
side nonce capability discovery.

Meanwhile, 2560 is going from Proposed to Draft.  We are allowed
to and already have performed minor amendments.  The "MUST
reject" clarification will be another.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Terry Hayes
> Sent: Wednesday, November 19, 2003 5:04 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
>
>
>
> Florian Oelmaier wrote on 11/19/2003, 4:29 PM:
> >
> > MY OPINION is to leave OCSPv1 as it is and draft an
> additional RfC
> > providing the extensions needed. Eventually we
> should add a short link
> > pointing to this OCSP-extension-RfC into RfC2560.
> >
>
> I also believe that this is the correct approach.
> Notice that the new extension(s)
> most likely will work in the OCSP v1 framework.
> There is no need to change
> OCSP to v2, or wait for a OCSP v2 to define this extension.
>
> Terry Hayes
>
>

Date: Thu, 20 Nov 2003 16:02:31 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Duplicates
Sender: [email-masked]

Am I the onky one getting two copies of most messages posted to the list?

Peter.

Am I the onky one getting two copies of most messages posted to the list?

Peter.

Date: Wed, 19 Nov 2003 17:03:32 -0800
From: "Terry Hayes" <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
To: [email-masked]
cc: [email-masked]
Organization: AOL
Sender: [email-masked]

Florian Oelmaier wrote on 11/19/2003, 4:29 PM:
> 
> MY OPINION is to leave OCSPv1 as it is and draft an additional RfC 
> providing the extensions needed. Eventually we should add a short link 
> pointing to this OCSP-extension-RfC into RfC2560. 
> 

I also believe that this is the correct approach.  Notice that the new extension(s)
most likely will work in the OCSP v1 framework.  There is no need to change
OCSP to v2, or wait for a OCSP v2 to define this extension.

Terry Hayes

Date: Wed, 19 Nov 2003 17:00:51 -0800
From: "Terry Hayes" <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
To: [email-masked]
Organization: AOL
Sender: [email-masked]

I prefer option 2.

A server that receives a request that includes an extension that it does not support should respond as
if that extension was not present in the request.  This is allowed by the processing rules for extensions.

A server that does not support the nonce extension should respond as if it was missing.  It should
send back a non-nonced response.

This position is not in conflict with the "client MUST reject" consensus.  It does conflict with the "MUST
incorporate" woding that has been proposed.  However I do not believe that there is any consensus on 
that part of the proposal.

Terry Hayes

Michael Myers wrote on 11/19/2003, 12:21 PM:
> 
> Terry, 
> 
> My comments embedded below largely revolve around what in your 
> opinion a *v1* caching server MUST send back in the event it 
> receives a nonced request but by system design is unable to 
> incorporate that nonce in a response. 
> 
> There are four options for v1: 
> 
> 1. Go silent and send back nothing; 
> 
> 2. Send back a non-nonced response anyway; 
> 
> 3. Signal back anything other than a definitive 
>    "good" or "revoked",  where "anything other" 
>    must be selected from 2560 as it is written; 
> 
> 4. Or the IETF and this WG does nothing and lets 
>    the market decide. 
> 
> Which of these v1 options do you prefer?  Extensions will lead 
> us to v2 and thus are excluded from the solution space. 
> 
> I will tell you my opinion: 
> 
> #1 opens the door to a needless sequence of retries 
>    that will lead PKI-using communities to further 
>    complain that PKI doesn't work. 
> 
> #2 is in direct conflict with the "MUST reject" 
>    consensus.  It flies in the face of the sound 
>    security principles ratified by the initial 
>    poll and as reiterated by our Area Director in 
>    his guidance to the WG. 
> 
> #3 could work if we could only agree on what 
>    that signal is with respect to running code. 
> 
> #4 is only included for completeness, else why are 
>    we even bothering to debate the issue. 
> 
> Mike 
> 
> 
> 
> 
> > -----Original Message----- 
> > From: Terry Hayes [mailto:[email-masked]] 
> > Sent: Wednesday, November 19, 2003 10:43 AM 
> > To: [email-masked] 
> > Cc: [email-masked] 
> > Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes) 
> > 
> > 
> > I also diagree with the "decision" recorded in the 
> > minutes of the WG meeting. 
> 
> We didn't decide so much as confirm the rough consensus of the 
> initial poll.  Clients MUST reject. 
> 
> > 
> > The OCSP RFC clearly states that extensions are 
> > optional, and need not be processed by either the 
> > client or the responder.  This proposal makes a 
> > significant change in the standard by requiring 
> > special-case processing for the nonce extension. 
> > This will cause existing implementations of 
> > responders to be non-conformant. 
> 
> The minutes do not propose an extension.  All is says is that 
> clients MUST reject. 
> 
> > I do not believe that the current RFC is broken in 
> > any way. 
> 
> Agree, it's not broken.  But it could use a little clarification 
> in this one area. 
> 
> > It provides a method for a client to 
> > request a fresh OCSP response, and a method for 
> > checking that an appropriate response was generated. 
> > This is the goal of this portion of the RFC, and it 
> > is satisfied by the existing extension and the 
> > existing processing requirements for extensions.  I 
> > agree that additional text that describes the 
> > processing by the client would make this clearer, but 
> > it seems to have been correctly interpreted by anyone 
> > hat has implemented a client based on the current wording. 
> 
> Strongly agree with your last point. 
> 
> > The current discussion seems to be motivated by an 
> > additional requirement that was not addressed in the 
> > original RFC.  This new requirement is to allow a 
> > client to accept a response that does not included a 
> > matching nonce, if the client can determine that the 
> > responder never includes nonces (such as a caching 
> > server). 
> 
> Yes, this is a new requirement, but perhaps better worded as 
> "nonce capability discovery". 
> 
> > There was an extension proposed on the list 
> > that would allow this requirment to be satisfied. 
> > This new extension would be compatible with the 
> > current wording for extension processing in the OCSP 
> > RFC, and could be defined within the current OCSP v1 
> > framework. 
> 
> Many ideas have been proposed and I'm sure we'll consider them 
> all in due course against a possible v2. Meanwhile there remains 
> this unresolved issue about what a v1 caching server MUST send 
> back to a nonced request. 
> 
> 
> > I think the concensus of the list was to leave the 
> > current RFC intact, and to work on defining an 
> > additional extension to handle the new requirement. 
> 
> All this discussion clearly indicates a need to at least clarify 
> the intended semantics of the nonce extension and a strong 
> consensus via the {MUST reject, MUST incoporate} poll as to what 
> that clarification should say. 
> 
> > 
> > Terry Hayes 

From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Thu, 20 Nov 2003 01:29:36 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

Hello all,

you all know my position regarding this issue: I agree with Terry Hayes,
Miguel Rodriguez, James Manger, Magnus Nystrom, Ryan M.Hurst and all the
others argumenting along that line in the discussion a few weeks ago. 

I strongly believe that the first poll on this issue does not help us in
deciding this issue (as stated by Miguel).

THE PROBLEM is that some clients want to support both types of
responders: caching responders (or better cached responses) and "live"
responders without knowing what type of responder they are talking to
beforehand. To allow for a client-policy driven decision regarding
trustworthiness while simultaneous maintaining technical
interoperability these clients want to get nonces where possible but
will accept nonce-less responses, too (if the local policy is met:
timeout for freshness, confirmation of a warning dialog by the user,
etc.). 

THE STATUS QUO is that the clients described above can be tricked by an
attacker to accept replies without nonces from a responder that would
support nonces. This problem is not intrinsic to the system but could be
solved using the protocol. At least one solution (see 4) is already
applied in the market.

THE SOLUTIONS. After a lot of discussion on this list, we have a set of
proposed solutions. In my eyes, all of these solutions would solve the
problem described above. Allow me to try and summarize the options
presented:

1) Proposal of Russ Housely et al at IETF Meeting:
Clients MUST reject replies without nonces to requests with nonces.
Servers MUST reply with an error to requests with nonce if they are not
able to generate nonces.

2) Proposal of Tom Gindin
(http://www.imc.org/ietf-pkix/mail-archive/msg07000.html): 
All responders (especially those supporting nonces) should add a boolean
NonceSupported extension 

3) Proposal of David Engberg
(http://www.imc.org/ietf-pkix/mail-archive/msg06838.html): 
All responders not supporting nonces should add a NonceUnsupported
extension

4) Proposal of Florian Oelmaier
(http://www.imc.org/ietf-pkix/mail-archive/msg06766.html): 
All responders supporting nonces should add a server generated nonces to
the response if there is no nonce in the request

IN MY OPINION solution 1 is neither rough consesus in the WG nor based
on running code. With proposal 1 clients will loose a lot of
configuration flexibility and within some the default configuration will
break. With proposal 1 servers will loose a lot of configuration
flexibility and some installations will break. With proposal 1 the RfC
contradicts itself regarding OPTIONAL extension handling at the server. 
All other options are perfectly acceptable from my point of view. I like
the idea of adding an extension (proposal 2 or 3) as it is clearly
defined, easily understandable and due to the extension system
completely in line with all running code and with the wording of the
RfC.

MY OPINION is to leave OCSPv1 as it is and draft an additional RfC
providing the extensions needed. Eventually we should add a short link
pointing to this OCSP-extension-RfC into RfC2560.

-- 
Florian Oelmaier
SyTrust

PS: ADDITIONALLY within the discussion a second idea was floating
around: Upon receiving a request with nonce, a "caching" responder
eventually wants to forward the request to a "live" responder in the
background. To decide this, the responder would like to know if the
client would accept a response without nonce or not. While this is not a
security issue, it may be important in some environments. Seeing the
discussion above, this could be solved simultaneous. There are also some
proposals to solve this problem: 
- critical flag for nonces in the request
- WillAcceptNoncelessResponse extension
- WillNotAcceptNoncelessResponse extension 

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 14:09:41 -0800
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: David Engberg [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2003 12:57 PM
>
> My preference would be a slight variant on Mike's #2:
> send back a  non-nonced response with a response
> extension indicating "nonceUnsupported".
>
> I think Mike's analysis for #2 is incomplete.  The
> original concensus was around the current behavior
> of clients in absence of this extension.

Dave,

Earlier today Steve wrote:  "I believe Russ's statement sets the
parameters for how we clarify this issue within the bounds of
OCSP v1."  Thus we need to determine, in part and if possible,
what a v1-based caching server MUST send back to a nonced
request using only the ASN.1 syntax defined by RFC 2560 as
written.  Your proposed nonceUnsupported, while a candidate for
v2 consideration, is clearly not within that v1 scope.

In v2, should it come to pass, we will no doubt entertain
ourselves to the point of exhaustion with all the proposals
currently on the table.  But in a v1 only context, we have four
options for an IETF standard governing OCSP caching server
action in the presence of a nonced request:  1) sever goes
silent; 2)ignore the nonce and send a non-nonced response
anyway; 3)send anything other than "good" or "revoked" as
selected from 2560's existing syntax; or 4) the WG does nothing
and lets the market sort it out.

v1 only, no new extensions.  How MUST a v1 caching server
respond to a nonced request?  Given the constrained solution
space, I prefer #3 using a non-nonced yet signed response value
of "unknown".

Mike

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-04.txt
Date: Wed, 19 Nov 2003 15:27:05 -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 Policies extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-04.txt
	Pages		: 8
	Date		: 2003-11-19
	
This document describes one certificate extension to explicitly 
state the Attribute Certificate (AC) policies that apply to a given 
Attribute Certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-04.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-acpolicies-extn-04.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-acpolicies-extn-04.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-acpolicies-extn-04.txt

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

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

--OtherAccess--

--NextPart--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 12:21:24 -0800
Importance: Normal
Sender: [email-masked]

Terry,

My comments embedded below largely revolve around what in your
opinion a *v1* caching server MUST send back in the event it
receives a nonced request but by system design is unable to
incorporate that nonce in a response.

There are four options for v1:

1. Go silent and send back nothing;

2. Send back a non-nonced response anyway;

3. Signal back anything other than a definitive
   "good" or "revoked",  where "anything other"
   must be selected from 2560 as it is written;

4. Or the IETF and this WG does nothing and lets
   the market decide.

Which of these v1 options do you prefer?  Extensions will lead
us to v2 and thus are excluded from the solution space.

I will tell you my opinion:

#1 opens the door to a needless sequence of retries
   that will lead PKI-using communities to further
   complain that PKI doesn't work.

#2 is in direct conflict with the "MUST reject"
   consensus.  It flies in the face of the sound
   security principles ratified by the initial
   poll and as reiterated by our Area Director in
   his guidance to the WG.

#3 could work if we could only agree on what
   that signal is with respect to running code.

#4 is only included for completeness, else why are
   we even bothering to debate the issue.

Mike

> -----Original Message-----
> From: Terry Hayes [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2003 10:43 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
>
>
> I also diagree with the "decision" recorded in the
> minutes of the WG meeting.

We didn't decide so much as confirm the rough consensus of the
initial poll.  Clients MUST reject.

>
> The OCSP RFC clearly states that extensions are
> optional, and need not be processed by either the
> client or the responder.  This proposal makes a
> significant change in the standard by requiring
> special-case processing for the nonce extension.
> This will cause existing implementations of
> responders to be non-conformant.

The minutes do not propose an extension.  All is says is that
clients MUST reject.

> I do not believe that the current RFC is broken in
> any way.

Agree, it's not broken.  But it could use a little clarification
in this one area.

> It provides a method for a client to
> request a fresh OCSP response, and a method for
> checking that an appropriate response was generated.
> This is the goal of this portion of the RFC, and it
> is satisfied by the existing extension and the
> existing processing requirements for extensions.  I
> agree that additional text that describes the
> processing by the client would make this clearer, but
> it seems to have been correctly interpreted by anyone
> hat has implemented a client based on the current wording.

Strongly agree with your last point.

> The current discussion seems to be motivated by an
> additional requirement that was not addressed in the
> original RFC.  This new requirement is to allow a
> client to accept a response that does not included a
> matching nonce, if the client can determine that the
> responder never includes nonces (such as a caching
> server).

Yes, this is a new requirement, but perhaps better worded as
"nonce capability discovery".

> There was an extension proposed on the list
> that would allow this requirment to be satisfied.
> This new extension would be compatible with the
> current wording for extension processing in the OCSP
> RFC, and could be defined within the current OCSP v1
> framework.

Many ideas have been proposed and I'm sure we'll consider them
all in due course against a possible v2. Meanwhile there remains
this unresolved issue about what a v1 caching server MUST send
back to a nonced request.

> I think the concensus of the list was to leave the
> current RFC intact, and to work on defining an
> additional extension to handle the new requirement.

All this discussion clearly indicates a need to at least clarify
the intended semantics of the nonce extension and a strong
consensus via the {MUST reject, MUST incoporate} poll as to what
that clarification should say.

> Terry Hayes

Date: Wed, 19 Nov 2003 10:42:40 -0800
From: "Terry Hayes" <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
To: [email-masked]
cc: [email-masked]
Organization: AOL
Sender: [email-masked]

I also diagree with the "decision" recorded in the minutes of the WG meeting.

The OCSP RFC clearly states that extensions are optional, and need not be processed by either the client or the responder.  This proposal makes a significant change in the standard by requiring special-case processing for the nonce extension.  This will cause existing implementations of responders to be non-conformant.

I do not believe that the current RFC is broken in any way.  It provides a method for a client to request a fresh OCSP response, and a method for checking that an appropriate response was generated.  This is the goal of this portion of the RFC, and it is satisfied by the existing extension and the existing processing requirements for extensions.  I agree that additional text that describes the processing by the client would make this clearer, but it seems to have been correctly interpreted by anyone that has implemented a client based on the current wording.

The current discussion seems to be motivated by an additional requirement that was not addressed in the original RFC.  This new requirement is to allow a client to accept a response that does not included a matching nonce, if the client can determine that the responder never includes nonces (such as a caching server).  There was an extension proposed on the list that would allow this requirment to be satisfied.  This new extension would be compatible with the current wording for extension processing in the OCSP RFC, and could be defined within the current OCSP v1 framework.

I think the concensus of the list was to leave the current RFC intact, and to work on defining an additional extension to handle the new requirement.

Terry Hayes

> 
> The core question is, how does the responder signal failure in a 
> way that enables closure of the protocol? 

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 08:29:00 -0800
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Stephen Kent
> Sent: Wednesday, November 19, 2003 6:56 AM
>
> . . .
>
> I believe Russ's statement sets the parameters
> for how we clarify this issue, within the bounds
> of OCSP v1.

At the risk of adding to my collection of PKIX battle
memorabilia yet more sticks, stones, arrows and flame residue,
what if caching servers send back a signed "unknown"?  It's
signed, cacheable and already in standing v1 codebases (or so
one presumes).

The only downside is that a client will have to retain state in
order to distinguish a true "unknown" from an "unknown due to
nonce" and thus trigger a non-nonced retry if so configured.

This would be in addition to "MUST reject", which protects the
client in the event it receives a non-nonced response anyway.

Mike

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 07:56:22 -0800
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Nystrom, Magnus
> Sent: Wednesday, November 19, 2003 6:16 AM
>
> . . .
>
> It seems to me that if any change is to be
> done on the responder side it would be better
> to state that a responder which receives a
> request with a critical nonce extension will
> have to provide a response back including that
> nonce or fail.

The core question is, how does the responder signal failure in a
way that enables closure of the protocol?

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 09:43:00 -0600
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C3AE81.8FADEBA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

My understanding about the poll is that is was about how many client
implementations would break as a consequence of the normative:
 
"Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."
 
   "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."
 
A majority responded "no breakage". After that the discussion turned to
the point Ryan mentions, that is, how clients can decide what to do when
receiving a nonceless response to a request with a nonce. There were
several proposals here, but this was not the purpose of the poll. Of
course one possibility is to always reject such responses. I think our
discussion, and the attention it got, showed that this issue is
important to the PKI community. I'd like to continue the discussion,
since we were getting good proposals.
 
My two cents,
 
Miguel A Rodriguez
SeguriDATA
Mexico
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: Wednesday, November 19, 2003 12:30 AM
To: Stephen Kent; Deacon, Alex
Cc: [email-masked]
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
 
Stephen - I agree with what you have written, however the statement in
question does not say that a client "SHOULD" or ought to reject it, it
mandates it my specifying it as a "MUST".
 
Since it is the client that requests the nonce and is the only one who
benefits from when it is used, it should be up to the client to decide
what to do with the response with or without it.
 
Ryan
 
  _____  

From: [email-masked] on behalf of Stephen Kent
Sent: Tue 11/18/2003 4:10 PM
To: Deacon, Alex
Cc: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
 
At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting
last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts
below
>from both the draft minutes sent by Steve and from the WG summary sent
by
>Tim)
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant.  
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this
subject in
>mid October.
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned
(nonceless) response to a client request that included a nonce, that
this is not conforming to the spirit of OCSP, even if the RFC did not
spell out this case in excruciating detail. Russ Housely reaffirmed
this in the quote I included in the minutes.

The question of what a server should do when it receives a request
with a nonce and is unable to comply is still up in the air, in my
opinion.  The list has discussed the merits and shortcomings of
having a server send an (unsigned) error message. Not sending any
response is certainly another option. A good fix to this problem may
have to await a revision of OCSP. But, in any case, a client that
sent a request with a nonce ought to reject a canned response, as
Russ said.

I don't see this clarification as changing the OCSPv1 spec.
Moreover, my reading of the responses to Mike's poll suggests that
the vast majority of servers and clients operate in an appropriate
manner in this regard, given the level of guidance provided in the
RFC.

There is no suggestion here that servers that issue only canned
responses are  bad. OCSP specifically allows for canned responses.
The issue is that a server should not issue a canned response to a
request that clearly requests a response that contains a nonce.

Steve

------=_NextPart_000_0005_01C3AE81.8FADEBA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<link rel=3DEdit-Time-Data href=3D"cid:[email-masked]">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: OCSPv1 and nonces (RE: draft meeting minutes)</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My understanding about the poll is =
that is
was about how many client implementations would break as a consequence =
of the normative:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;Clients
that elect to include a request nonce<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>SHALL reject =
responses
that fail to include<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>the client's =
nonce
from the associated request.&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>&quot;Correspondingly, =
upon
receipt of a request<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>containing a =
nonce, a
responder SHALL include<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>the value of =
such
nonce in the production of<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>the =
associated
response.&quot;<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A majority responded &#8220;no =
breakage&#8221;.
After that the discussion turned to the point Ryan mentions, that is, =
how clients
can decide what to do when receiving a nonceless response to a request =
with a
nonce. There were several proposals here, but this was not the purpose =
of the
poll. Of course one possibility is to always reject such responses. I =
think our
discussion, and the attention it got, showed that this issue is =
important to
the PKI community. I&#8217;d like to continue the discussion, since we =
were
getting good proposals.<o:p></o:p></span></font></p>

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

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

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

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

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

<p class=3DMsoNormal><st1:country-region><st1:place><font size=3D2 =
color=3Dnavy
  face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Mexico</span></fo=
nt></st1:place></st1:country-region><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

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

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Ryan M. Hurst<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, November =
19, 2003
12:30 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stephen Kent; Deacon, =
Alex<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: OCSPv1 and =
nonces
(RE: draft meeting minutes)</span></font></p>

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

<div id=3DidOWAReplyText5388>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Stephen - I agree with what you =
have
written, however the statement in question does not say that a client
&quot;SHOULD&quot; or ought to reject it, it mandates it my specifying =
it as a
&quot;MUST&quot;.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Since it is the client that requests the nonce and is =
the
only one who&nbsp;benefits from when it is used, it should be up to the =
client
to decide what to do with the response with or without =
it.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

</div>

<div>

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] on behalf of Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tue 11/18/2003 4:10 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Deacon, Alex<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: OCSPv1 and =
nonces
(RE: draft meeting minutes)</span></font><o:p></o:p></p>

</div>

<div>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>At 14:44
-0800 11/18/03, Deacon, Alex wrote:<br>
&gt;Hi,<br>
&gt;<br>
&gt;I was surprised to read about the decision made at the PKIX meeting =
last<br>
&gt;week in MN regarding the action to update OCSPv1 to require servers =
to<br>
&gt;include the nonce in the response or return an error.&nbsp; (See =
excerpts
below<br>
&gt;from both the draft minutes sent by Steve and from the WG summary =
sent by<br>
&gt;Tim)<br>
&gt;<br>
&gt;Let me summarize the reasons I feel this decision is a bad idea:<br>
&gt;<br>
&gt;1) It will cause currently conformant OCSPv1 implementations to =
be<br>
&gt;non-conformant.<br>
&gt;<br>
&gt;2) It will cause OCSP profiles defined in other standards bodies to =
be<br>
&gt;non-conformant.&nbsp;&nbsp;<br>
&gt;<br>
&gt;3) It seems to be contrary to the &quot;rough consensus&quot; I =
thought was
clear<br>
&gt;based on the various polls Mike Myers posted to the list on this =
subject in<br>
&gt;mid October.<br>
&gt;<br>
&gt;Its to late in the game to make such a large change to basic =
OCSPv1<br>
&gt;behavior.&nbsp; Keep OCSPv1 as it is.<br>
&gt;<br>
<br>
Alex,<br>
<br>
There is a clear feeling that when a server returns a canned<br>
(nonceless) response to a client request that included a nonce, that<br>
this is not conforming to the spirit of OCSP, even if the RFC did =
not<br>
spell out this case in excruciating detail. Russ Housely reaffirmed<br>
this in the quote I included in the minutes.<br>
<br>
The question of what a server should do when it receives a request<br>
with a nonce and is unable to comply is still up in the air, in my<br>
opinion.&nbsp; The list has discussed the merits and shortcomings of<br>
having a server send an (unsigned) error message. Not sending any<br>
response is certainly another option. A good fix to this problem may<br>
have to await a revision of OCSP. But, in any case, a client that<br>
sent a request with a nonce ought to reject a canned response, as<br>
Russ said.<br>
<br>
I don't see this clarification as changing the OCSPv1 spec.<br>
Moreover, my reading of the responses to Mike's poll suggests that<br>
the vast majority of servers and clients operate in an appropriate<br>
manner in this regard, given the level of guidance provided in the<br>
RFC.<br>
<br>
There is no suggestion here that servers that issue only canned<br>
responses are&nbsp; bad. OCSP specifically allows for canned =
responses.<br>
The issue is that a server should not issue a canned response to a<br>
request that clearly requests a response that contains a nonce.<br>
<br>
Steve</span></font><o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_0005_01C3AE81.8FADEBA0--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 07:41:35 -0800
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Manger, James H
> Sent: Tuesday, November 18, 2003 7:16 PM
>
> . . .
>
> Michael Myers initiated a poll about adding an error
> code that responders would use when they could not
> copy a nonce from a request to a response.  The poll
> was overwhelmingly rejected: something like 1 Yes, 20
> No.  Clearly a new error code cannot be added.
> Trying to add text that a client must always reject a
> response missing a nonce cannot be added as it would
> be against the spirit of the overwhelming poll result.

Yet the preceding poll (clients MUST reject and servers MUST
incorporate) established no breakage in an overwhelming majority
of implemented cases.  Implemented, mind you: running code,
rough consensus and all that.

Thus in the case of "MUST reject", the clarification as recorded
in the minutes simply codifies what has already been done
correctly even in the absence of a tutorial in normative
language on the proper use of nonces in a security protocol.

The only issue that emerged following the first poll was that
two out of twelve server side implementations would be unable to
comply with "MUST incorporate" due to their reliance on
pre-produced responses to achieve cache-based cost efficiency.

This led to "SHOULD incorporate but if can't, then SHALL <X>".
A variety of syntax, semantics and rules of behavior regarding X
were and continue to be discussed.

Read the minutes carefully and note that the language recorded
there does NOT call for an error code.  It simply asserts in
normative language a fundamental principle of security
engineering that seems to have been better understood than it
was documented.

So, that leaves us with yet having to determine a value for X.
The error code poll asked us to consider one such idea.  It did
NOT seek an implicit repudiation of the poll that preceded it,
wherein "MUST reject" was very clearly established.

Mike

Date: Wed, 19 Nov 2003 09:55:55 -0500
To: "Manger, James H" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Cc: <[email-masked]>
Sender: [email-masked]

At 13:15 +1000 11/19/03, Manger, James H wrote:
>I agree with Alex Deacon (& Ryan), not Stephen Kent, on this issue.
>
>Michael Myers initiated a poll about adding an error code that 
>responders would use when they could not copy a nonce from a request 
>to a response.  The poll was overwhelmingly rejected: something like 
>1 Yes, 20 No.  Clearly a new error code cannot be added.  Trying to 
>add text that a client must always reject a response missing a nonce 
>cannot be added as it would be against the spirit of the 
>overwhelming poll result.

James,

My comments addressed the question of proper behavior of clients and 
servers when there is a mismatch between the type of request offered 
and the capability of the server to respond consistent with the 
request type.  The poll I alluded too, perhaps not precisely enough, 
was on that topic.  I was not referring to the question of whether we 
should send an error message.

>Alex might not have to worry as the minutes did not actually say a 
>new version of OCSPv1 would be produced (apparently Tim Polk's "WG 
>summary" did but I have not seen that).  The previous poll shows it 
>would not be supported - and I don't think you are allowed to go 
>straight from editor to area director, bypassing the working group.

My comments did not suggest that we would change OCSPv1 to impose a 
new requirement to send new messages, etc. But there is certainly 
room to clarify what some folks see as an ambiguous area of the state 
machine.

>P.S. Russ Housley's quote fails to accommodate an OCSP client that 
>puts a nonce in an OCSP request because the client **prefers** to 
>get replay protection, though may be willing to forgo that 
>protection for the sake of a more scalable system if only cached 
>responses are available.  It would be ok to add text saying "a 
>client requiring replay detection can include a nonce in the request 
>and reject a nonce-less response".

Your comment immediately above assumes a possible motivation on the 
part of some clients who insert a nonce in a request. I can't rule 
out the possibility that some clients may behave in this fashion, but 
this assumption cannot generally be inferred from the OCSP spec.

We recognize now that the spec does not accommodate all the possible 
ways that a client and a server might interact, when the server 
supports only canned responses. To fix this problem completely will 
probably require a revised OCSP, probably with a new version number. 
Howeverm in the interim, it is reasonable to clarify what clients and 
servers should do under these circumstances, without changing the 
bits on the wire, and without introducing vulnerabilities of the sort 
that the use of nonces is designed to avoid. I believe Russ's 
statement sets the parameters for how we clarify this issue, within 
the bounds of OCSP v1.

Steve

From: "Nystrom, Magnus" <[email-masked]>
Reply-To: "Nystrom, Magnus" <[email-masked]>
To: [email-masked]
Date: Wed, 19 Nov 2003 15:15:53 +0100 (W. Europe Standard Time)
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Sender: [email-masked]

James Manger wrote:

[...]
> P.S. Russ Housley's quote fails to accommodate an OCSP client that puts
> a nonce in an OCSP request because the client **prefers** to get replay
> protection, though may be willing to forgo that protection for the sake
> of a more scalable system if only cached responses are available.  It
> would be ok to add text saying "a client requiring replay detection can
> include a nonce in the request and reject a nonce-less response".

Exactly. Nonces are extensions, and 2560 says that its extension model is
"based on the extension model employed in X.509 version 3 certificates see
[RFC2459]. Support for all extensions is optional for both clients and
responders." As we know, the semantics for any non-critical extension is
"a non-critical extension MAY be ignored" [RFC3280].

Hence, as I see it, an OCSP responder is free to ignore any non-critical
OCSP extensions, including nonces, and yet be completely compliant. RFC
2560 does not say anything about the nonce extension being critical (in
fact, it recommends it to not be), and this is reflected in the behavior
of - currently conformant - OCSP responders. . It seems to me that if any
change is to be done on the responder side it would be better to state
that a responder which receives a request with a critical nonce extension
will have to provide a response back including that nonce or fail.

-- Magnus

Date: Wed, 19 Nov 2003 09:11:51 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Alice Sturgeon <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
Sender: [email-masked]

Alice,

Does this new document addresses the issues I raised to the IESG during the 
last call ?

If yes, would you please provide a resolution for my comments.

Denis

> 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 Warranty Certificate Extension
> 	Author(s)	: D. Linsenbardt, S. Pontius, A. Sturgeon
> 	Filename	: draft-ietf-pkix-warranty-extn-04.txt
> 	Pages		: 8
> 	Date		: 2003-11-18
> 	
> This document describes a certificate extension to explicitly state
> the warranty offered by a Certificate Authority (CA) for a the
> certificate containing the extension.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-04.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-warranty-extn-04.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-warranty-extn-04.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.

Content-class: urn:content-classes:message
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 22:29:45 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Deacon, Alex" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3AE66.E1185F7E"

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

Stephen - I agree with what you have written, however the statement in =
question does not say that a client "SHOULD" or ought to reject it, it =
mandates it my specifying it as a "MUST".
=20
Since it is the client that requests the nonce and is the only one who =
benefits from when it is used, it should be up to the client to decide =
what to do with the response with or without it.
=20
Ryan

________________________________

From: [email-masked] on behalf of Stephen Kent
Sent: Tue 11/18/2003 4:10 PM
To: Deacon, Alex
Cc: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting =
last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts =
below
>from both the draft minutes sent by Steve and from the WG summary sent =
by
>Tim)
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant. =20
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this =
subject in
>mid October.
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned
(nonceless) response to a client request that included a nonce, that
this is not conforming to the spirit of OCSP, even if the RFC did not
spell out this case in excruciating detail. Russ Housely reaffirmed
this in the quote I included in the minutes.

The question of what a server should do when it receives a request
with a nonce and is unable to comply is still up in the air, in my
opinion.  The list has discussed the merits and shortcomings of
having a server send an (unsigned) error message. Not sending any
response is certainly another option. A good fix to this problem may
have to await a revision of OCSP. But, in any case, a client that
sent a request with a nonce ought to reject a canned response, as
Russ said.

I don't see this clarification as changing the OCSPv1 spec.
Moreover, my reading of the responses to Mike's poll suggests that
the vast majority of servers and clients operate in an appropriate
manner in this regard, given the level of guidance provided in the
RFC.

There is no suggestion here that servers that issue only canned
responses are  bad. OCSP specifically allows for canned responses.
The issue is that a server should not issue a canned response to a
request that clearly requests a response that contains a nonce.

Steve

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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7097.0">=0A=
<TITLE>Re: OCSPv1 and nonces  (RE: draft meeting minutes)</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText5388 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Stephen - I =
agree with what =0A=
you have written, however the statement in question does not say that a =
client =0A=
"SHOULD" or ought to reject it, it mandates it my specifying it as a =0A=
"MUST".</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Since it is the client that =
requests the =0A=
nonce and is the only one who&nbsp;benefits from when it is used, it =
should be =0A=
up to the client to decide what to do with the response with or without =0A=
it.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of =0A=
Stephen Kent<BR><B>Sent:</B> Tue 11/18/2003 4:10 PM<BR><B>To:</B> =
Deacon, =0A=
Alex<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> Re: OCSPv1 and =
nonces =0A=
(RE: draft meeting minutes)<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>At 14:44 -0800 11/18/03, Deacon, Alex =0A=
wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;I was surprised to read about the =
decision made =0A=
at the PKIX meeting last<BR>&gt;week in MN regarding the action to =
update OCSPv1 =0A=
to require servers to<BR>&gt;include the nonce in the response or return =
an =0A=
error.&nbsp; (See excerpts below<BR>&gt;from both the draft minutes sent =
by =0A=
Steve and from the WG summary sent by<BR>&gt;Tim)<BR>&gt;<BR>&gt;Let me =0A=
summarize the reasons I feel this decision is a bad =
idea:<BR>&gt;<BR>&gt;1) It =0A=
will cause currently conformant OCSPv1 implementations to =0A=
be<BR>&gt;non-conformant.<BR>&gt;<BR>&gt;2) It will cause OCSP profiles =
defined =0A=
in other standards bodies to =0A=
be<BR>&gt;non-conformant.&nbsp;&nbsp;<BR>&gt;<BR>&gt;3) It seems to be =
contrary =0A=
to the "rough consensus" I thought was clear<BR>&gt;based on the various =
polls =0A=
Mike Myers posted to the list on this subject in<BR>&gt;mid =0A=
October.<BR>&gt;<BR>&gt;Its to late in the game to make such a large =
change to =0A=
basic OCSPv1<BR>&gt;behavior.&nbsp; Keep OCSPv1 as it =0A=
is.<BR>&gt;<BR><BR>Alex,<BR><BR>There is a clear feeling that when a =
server =0A=
returns a canned<BR>(nonceless) response to a client request that =
included a =0A=
nonce, that<BR>this is not conforming to the spirit of OCSP, even if the =
RFC did =0A=
not<BR>spell out this case in excruciating detail. Russ Housely =0A=
reaffirmed<BR>this in the quote I included in the minutes.<BR><BR>The =
question =0A=
of what a server should do when it receives a request<BR>with a nonce =
and is =0A=
unable to comply is still up in the air, in my<BR>opinion.&nbsp; The =
list has =0A=
discussed the merits and shortcomings of<BR>having a server send an =
(unsigned) =0A=
error message. Not sending any<BR>response is certainly another option. =
A good =0A=
fix to this problem may<BR>have to await a revision of OCSP. But, in any =
case, a =0A=
client that<BR>sent a request with a nonce ought to reject a canned =
response, =0A=
as<BR>Russ said.<BR><BR>I don't see this clarification as changing the =
OCSPv1 =0A=
spec.<BR>Moreover, my reading of the responses to Mike's poll suggests =0A=
that<BR>the vast majority of servers and clients operate in an =0A=
appropriate<BR>manner in this regard, given the level of guidance =
provided in =0A=
the<BR>RFC.<BR><BR>There is no suggestion here that servers that issue =
only =0A=
canned<BR>responses are&nbsp; bad. OCSP specifically allows for canned =0A=
responses.<BR>The issue is that a server should not issue a canned =
response to =0A=
a<BR>request that clearly requests a response that contains a =0A=
nonce.<BR><BR>Steve<BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3AE66.E1185F7E--

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

content-class: urn:content-classes:message
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 13:15:33 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I agree with Alex Deacon (& Ryan), not Stephen Kent, on this issue.

Michael Myers initiated a poll about adding an error code that responders would use when they could not copy a nonce from a request to a response.  The poll was overwhelmingly rejected: something like 1 Yes, 20 No.  Clearly a new error code cannot be added.  Trying to add text that a client must always reject a response missing a nonce cannot be added as it would be against the spirit of the overwhelming poll result.

Alex might not have to worry as the minutes did not actually say a new version of OCSPv1 would be produced (apparently Tim Polk's "WG summary" did but I have not seen that).  The previous poll shows it would not be supported - and I don't think you are allowed to go straight from editor to area director, bypassing the working group.

P.S. Russ Housley's quote fails to accommodate an OCSP client that puts a nonce in an OCSP request because the client **prefers** to get replay protection, though may be willing to forgo that protection for the sake of a more scalable system if only cached responses are available.  It would be ok to add text saying "a client requiring replay detection can include a nonce in the request and reject a nonce-less response".

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, 19 November 2003 11:11 AM
To: Deacon, Alex
Cc: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts below
>from both the draft minutes sent by Steve and from the WG summary sent by
>Tim) 
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant.   
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this subject in
>mid October. 
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned 
(nonceless) response to a client request that included a nonce, that 
this is not conforming to the spirit of OCSP, even if the RFC did not 
spell out this case in excruciating detail. Russ Housely reaffirmed 
this in the quote I included in the minutes.

The question of what a server should do when it receives a request 
with a nonce and is unable to comply is still up in the air, in my 
opinion.  The list has discussed the merits and shortcomings of 
having a server send an (unsigned) error message. Not sending any 
response is certainly another option. A good fix to this problem may 
have to await a revision of OCSP. But, in any case, a client that 
sent a request with a nonce ought to reject a canned response, as 
Russ said.

I don't see this clarification as changing the OCSPv1 spec. 
Moreover, my reading of the responses to Mike's poll suggests that 
the vast majority of servers and clients operate in an appropriate 
manner in this regard, given the level of guidance provided in the 
RFC.

There is no suggestion here that servers that issue only canned 
responses are  bad. OCSP specifically allows for canned responses. 
The issue is that a server should not issue a canned response to a 
request that clearly requests a response that contains a nonce.

Steve

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 18:43:10 -0800
Importance: Normal
Sender: [email-masked]

The initial poll I sent out on 9/24/03 was worded as follows:

[Who] would break as a consequence of the following normative
language:

    "Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."

    "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."

11 of 12 client side implementors and 10 of 12 server side
implementors responded "no breakage".

Mike

Content-class: urn:content-classes:message
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 17:03:20 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I agree with this, in-fact it appears to be in conflict with the earlier
discussions on the thread on the same topic.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Deacon, Alex
Sent: Tuesday, November 18, 2003 2:44 PM
To: [email-masked]
Subject: OCSPv1 and nonces (RE: draft meeting minutes)

Hi,

I was surprised to read about the decision made at the PKIX meeting last
week in MN regarding the action to update OCSPv1 to require servers to
include the nonce in the response or return an error.  (See excerpts
below
from both the draft minutes sent by Steve and from the WG summary sent
by
Tim)  

Let me summarize the reasons I feel this decision is a bad idea:

1) It will cause currently conformant OCSPv1 implementations to be
non-conformant. 

2) It will cause OCSP profiles defined in other standards bodies to be
non-conformant.    

3) It seems to be contrary to the "rough consensus" I thought was clear
based on the various polls Mike Myers posted to the list on this subject
in
mid October.  

Its to late in the game to make such a large change to basic OCSPv1
behavior.  Keep OCSPv1 as it is.  

Alex

========================

>From the WG summary
> 3. OCSP v1 will be revised to specify the server and client
> processing requirements where the client included a nonce in 
> the request.  The revised document will require servers to include
> the nonce in the response or return an error.

>From the Draft Meeting Minutes  
> OCSPv1 problem - Mike Meyers (Traceroute)
> 	OCSP has a facility in which a client may include a nonce in 
> a request, to detect and reject replays of responses. Unfortunately, 
> the RFC did not make perfectly clear that a client MUST reject a 
> response that did not include a nonce, if the client included a nonce 
> in the request. Similarly, the RFC did not make clear what a server 
> should do if it receives a request with a nonce, but is incapable of 
> generating a response containing a nonce, i.e., a server that deals 
> only with pre-signed responses.
> 	A straw poll indicated that the vast majority of clients deal 
> with these issues properly, but not all. OCSP servers that rely on 
> caching do not generate a unique response for each request, so they 
> omit nonces.  An error could be returned by a server to indicate the 
> inability to respond properly to a request with a nonce, but errors 
> are not signed, so this does not address the security concern.
> 	Russ Housley, the cognizant AD made the following observation 
> re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
> replay protection is expected. Therefore, the OCSP Responder MUST 
> include the same nonce value in the OCSP Response.  If the OCSP 
> Client receives an OCSP Response that fails to include the correct 
> nonce value, it MUST be rejected."

Date: Tue, 18 Nov 2003 19:10:50 -0500
To: "Deacon, Alex" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: OCSPv1 and nonces  (RE: draft meeting minutes)
Cc: [email-masked]
Sender: [email-masked]

At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts below
>from both the draft minutes sent by Steve and from the WG summary sent by
>Tim) 
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant.   
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this subject in
>mid October. 
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned 
(nonceless) response to a client request that included a nonce, that 
this is not conforming to the spirit of OCSP, even if the RFC did not 
spell out this case in excruciating detail. Russ Housely reaffirmed 
this in the quote I included in the minutes.

The question of what a server should do when it receives a request 
with a nonce and is unable to comply is still up in the air, in my 
opinion.  The list has discussed the merits and shortcomings of 
having a server send an (unsigned) error message. Not sending any 
response is certainly another option. A good fix to this problem may 
have to await a revision of OCSP. But, in any case, a client that 
sent a request with a nonce ought to reject a canned response, as 
Russ said.

I don't see this clarification as changing the OCSPv1 spec. 
Moreover, my reading of the responses to Mike's poll suggests that 
the vast majority of servers and clients operate in an appropriate 
manner in this regard, given the level of guidance provided in the 
RFC.

There is no suggestion here that servers that issue only canned 
responses are  bad. OCSP specifically allows for canned responses. 
The issue is that a server should not issue a canned response to a 
request that clearly requests a response that contains a nonce.

Steve

From: "Deacon, Alex" <[email-masked]>
To: [email-masked]
Subject: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 14:44:12 -0800
Sender: [email-masked]

Hi,

I was surprised to read about the decision made at the PKIX meeting last
week in MN regarding the action to update OCSPv1 to require servers to
include the nonce in the response or return an error.  (See excerpts below
from both the draft minutes sent by Steve and from the WG summary sent by
Tim)  

Let me summarize the reasons I feel this decision is a bad idea:

1) It will cause currently conformant OCSPv1 implementations to be
non-conformant. 

2) It will cause OCSP profiles defined in other standards bodies to be
non-conformant.    

3) It seems to be contrary to the "rough consensus" I thought was clear
based on the various polls Mike Myers posted to the list on this subject in
mid October.  

Its to late in the game to make such a large change to basic OCSPv1
behavior.  Keep OCSPv1 as it is.  

Alex

========================

>From the WG summary
> 3. OCSP v1 will be revised to specify the server and client
> processing requirements where the client included a nonce in 
> the request.  The revised document will require servers to include
> the nonce in the response or return an error.

>From the Draft Meeting Minutes  
> OCSPv1 problem - Mike Meyers (Traceroute)
> 	OCSP has a facility in which a client may include a nonce in 
> a request, to detect and reject replays of responses. Unfortunately, 
> the RFC did not make perfectly clear that a client MUST reject a 
> response that did not include a nonce, if the client included a nonce 
> in the request. Similarly, the RFC did not make clear what a server 
> should do if it receives a request with a nonce, but is incapable of 
> generating a response containing a nonce, i.e., a server that deals 
> only with pre-signed responses.
> 	A straw poll indicated that the vast majority of clients deal 
> with these issues properly, but not all. OCSP servers that rely on 
> caching do not generate a unique response for each request, so they 
> omit nonces.  An error could be returned by a server to indicate the 
> inability to respond properly to a request with a nonce, but errors 
> are not signed, so this does not address the security concern.
> 	Russ Housley, the cognizant AD made the following observation 
> re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
> replay protection is expected. Therefore, the OCSP Responder MUST 
> include the same nonce value in the OCSP Response.  If the OCSP 
> Client receives an OCSP Response that fails to include the correct 
> nonce value, it MUST be rejected."

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
Date: Tue, 18 Nov 2003 15:09: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		: Internet X.509 Public Key Infrastructure Warranty Certificate Extension
	Author(s)	: D. Linsenbardt, S. Pontius, A. Sturgeon
	Filename	: draft-ietf-pkix-warranty-extn-04.txt
	Pages		: 8
	Date		: 2003-11-18
	
This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for a the
certificate containing the extension.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-04.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-warranty-extn-04.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-warranty-extn-04.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-warranty-extn-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-warranty-extn-04.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: The IESG <[email-masked]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Proxy  Certificate Profile' to Proposed Standard 
Reply-to: [email-masked]
Date: Mon, 17 Nov 2003 16:04:14 -0500
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure (X.509) 
WG to consider the following document:

- 'Internet X.509 Public Key Infrastructure Proxy Certificate Profile '
   <draft-ietf-pkix-proxy-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2003-12-01.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-09.txt

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-09.txt
Date: Mon, 17 Nov 2003 11:07:02 -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 Proxy Certificate Profile
	Author(s)	: S. Tuecke
	Filename	: draft-ietf-pkix-proxy-09.txt
	Pages		: 46
	Date		: 2003-11-11
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-09.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-proxy-09.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-proxy-09.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-proxy-09.txt

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

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

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Date: Mon, 17 Nov 2003 15:05:17 +0100
Sender: [email-masked]

Just to set the record straight: Another consortium has indeed
[also] found the existings keygen/certreq mechanisms largely
inferior and will publish a draft solution in a couple of months
or so.  I just talked to one of the architects, and he confirmed that
it will support the kind of stuff that most of the proprietary solutions
already do, such as key-container co-signing, passphrase policy
control, and multi-key generation.

/a

Date: Mon, 17 Nov 2003 09:13:22 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01
Sender: [email-masked]

Santosh,

> Denis:
> 
> "R" also helps with adversary finding out some SII when an off-line,
> exhaustive dictionary attack is conducted.  With "R" in there, the adversary
> has to attack each certificate.  Without "R", the adversary can try random
> SII and if it matches a certificate, he has accomplished something.

As I said, this depends of the length of the SII, i.e. the difficulty to 
guess it. So R should be optional.

Denis

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Denis Pinkas
> Sent: Friday, November 14, 2003 4:32 AM
> To: Jongwook, Park
> Cc: [email-masked]; [email-masked]; Russ Housley; [email-masked]; Bill
> Burr; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Comments on draft-ietf-pkix-sim-01
> 
> 
> 
> Park,
> 
> Thank you for the explanations.
> 
> 
>>Denis:
>>
>>I think you catch on the basic idea of this draft exactly. Generally,
>>the DN in the 'subject' or 'subjectAltName' extension must be unique 
>>for each person. However, it is very difficult to identify that the 
>>subject of certificates is in fact the right person issued by CA since 
>>many people often have the same name.
>>
>>To solve the above problem, this document don't use the DN for
>>including the non-public data since the information in DN can't meet 
>>the requirement and is likely to disclosing private data. 
>>Alternatively, this draft proposes the PII(Privacy Identification 
>>Information) structure which is encrypted form of any sensitive 
>>identifier and finally put into the 'subjectAltName' 'GeneralizedName' 
>>'otherName' field. This way can be regarded as a complementary method 
>>for the shortcoming of the DN.
>>
>>PII structure is defined as follows :
>>
>>PII = H(R || SIItype || H (R || P || SII))
>>where R : 160-bit random number, P : Password, SII : Sensitive
>>Identification Identifier and H : Cryptographically secure hash 
>>function such as SHA-1, not MD2 or MD5.
>>
>>PII structure can be applied to the various situations in different
>>ways in accordance with the RP's security environments. Please refer 
>>to the section 5. Example Usage of PII of the draft for details. As a 
>>first example, let us suppose the RP already know the SII of the 
>>certificate holder via out of band. In this case, certificate holder 
>>should send R, P and his certificate containing the PII. Then RP can 
>>figure out if the PII in cert and another PII' calculated itself from 
>>R, P and SII already obtained are identical or not. It is definitely 
>>clear that R and P should be transmitted in a secure channel.
> 
> 
> R is only needed, if the SII is too short, to optionnally hide the value of 
> SII by preventing guessing attacks. If the SII value is long enough, then R 
> is no more needed. So R should be optional.
> 
> In the ASN.1 description of the SIM :
> 
>   - 1�  the SIItype field is missing,
>   - 2�  R should be OPTIONAL,
>   - 3�  an indicator should added to say whether or not
>         a password is required in the computation.
> 
> Note: if neither R and P are present and the SII is long enough, then we 
> have the proposal I made in my previous e-mail:
> 
> Include in the certificate a hash of "personal information" that can be
> revealed by the certificate holder and thus any relying party to which this
> information is disclosed can verify it (usually once).
> 
> Denis
> 
> 
> 
> 
>>For another example, suppose such context where some people don't
>>really want to divulge any hint of his sensitive identifier to RPs. 
>>Maybe it's a kind of same case why we need the Proof of Possession 
>>(POP) in RFC2510. Anyway, please note the PII is the double-hashed 
>>structure. That is to say, the subject send only intermediate value, 
>>H(R || P || SII) to RP without disclosing the SII. Then relying party 
>>can calculates H ( R || SIItype || intermediate value) and verifies 
>>whether this value is equal to the PII in the certificate. Finally, RP 
>>can guess the certificate holder has right certificate even if it 
>>doesn't know the value of SII itself.
>>
>>Alike the above procedures, the certificate holder should be send R,
>>P, SII and PII in a cert if the RP doesn't have any information about 
>>the certificate holder. The rest of the verification is similar to the 
>>first two cases.
>>
>>In conclusion, PII structure is cryptographically secure and efficient
>>scheme to protect personal information although it seems to be 
>>complicated at a glance.
>>
>>Best regards,
>>Park.
>>
>>
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>Sent: Friday, November 07, 2003 3:39 AM
>>To: pkix
>>Subject: Comments on draft-ietf-pkix-sim-01
>>
>>I have always wondered about the goal of this document, since it is
>>not crystal clear.
>>
>>It seems that the goal is to allow a relying party to determine
>>whether the subject of a particular certificate is the right person. 
>>This is currently difficult since there might be not enough 
>>information in the DN and disclosing more information in the DN would 
>>be against privacy.
>>
>>Is it the basic motivation of this document ?
>>
>>There is however an additional property of the "solution" (or is it a
>>real requirement ?) :
>>
>>    Furthermore, the subject can prove to the
>>    relying party that they are associated with a valid identification
>>    with out disclosing the identifier.
>>
>>This requirement is not crystal clear. What is a valid identification
>>? If it is a bank account number, is it a number with the right Luhn 
>>code computation in it and an existing bank identification number in 
>>it ?
>>
>>Now the solution is rather complicated and it can be seen that an
>>encryption channel is required. A high level view of the goal(s?) and 
>>the advantages of the solution is currently missing.
>>
>>There might be a much simpler solution to solve the basic problem that
>>is trying to be solved:
>>
>>Include in the certificate a hash of "personal information" that can
>>be revealed by the certifcate holder and thus any relying party to 
>>which this information is disclosed can verify it (usually once).
>>
>>
>>Denis
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sun, 16 Nov 2003 10:36:48 -0500
Importance: Normal
Sender: [email-masked]

Vadim:

This seems secure.  However, if the various certificate issuers used the
same p, q, and g for creating the public value of a given SII, it may offer
an opportunity to link different pseudo identities via the attribute to the
same person.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vadim Fedukovich
Sent: Saturday, November 15, 2003 9:18 AM
To: Jongwook, Park
Cc: 'Denis Pinkas'; [email-masked]; [email-masked]; Russ Housley;
[email-masked]; Bill Burr; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01

Dear Park,

yes PII suggested makes it unpractical trying to learn protected data unless
the password was disclosured to some party to let it verify the binding.
Once sent out, no control is here anymore and the password could be sent
further to other parties, to prove the binding. Maybe one can use proofs of
knowledge instead to stay in control of sensitive information. That is, run
proofs yourself using non-X.509 tools and only include proofs-bootstrapping
data in certificates issued.

For example, to prove the number SII is bound to ID certified one can choose
a new fresh random nonce t and send (C, T) to the verifier:
     C = Hash(ID, p, g, (g^{t * SII} mod p))
     T = g^t mod p
where ID is name/locality/country from the certificate and g is a generator
over prime filed (mod p).

The verifier could test that (T^{SII} mod p) corresponds to C, ID, g, p
Given strong hash function and hard discrete logarithm problem such a prof
should be convincing for the verifier.

Yes, the basic prof above could be running by anyone for any ID so one
should include some (private exponent) number in the verification equation
and include corresponding public value (g^{private} mod p) in the
certificate issued.

One can elaborate providing the whole idea looks acceptable

regards,
Vadim

On Fri, Nov 07, 2003 at 09:27:31PM +0900, Jongwook, Park wrote:
> 
> 
> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally, 
> the DN in the 'subject' or 'subjectAltName' extension must be unique 
> for each person. However, it is very difficult to identify that the 
> subject of certificates is in fact the right person issued by CA since 
> many people often have the same name.
> 
> To solve the above problem, this document don't use the DN for 
> including the non-public data since the information in DN can't meet 
> the requirement and is likely to disclosing private data. 
> Alternatively, this draft proposes the PII(Privacy Identification 
> Information) structure which is encrypted form of any sensitive 
> identifier and finally put into the 'subjectAltName' 'GeneralizedName' 
> 'otherName' field. This way can be regarded as a complementary method 
> for the shortcoming of the DN.
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive 
> Identification Identifier and H : Cryptographically secure hash 
> function such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different 
> ways in accordance with the RP's security environments. Please refer 
> to the section 5. Example Usage of PII of the draft for details. As a 
> first example, let us suppose the RP already know the SII of the 
> certificate holder via out of band. In this case, certificate holder 
> should send R, P and his certificate containing the PII. Then RP can 
> figure out if the PII in cert and another PII' calculated itself from 
> R, P and SII already obtained are identical or not. It is definitely 
> clear that R and P should be transmitted in a secure channel.
> 
> For another example, suppose such context where some people don't 
> really want to divulge any hint of his sensitive identifier to RPs. 
> Maybe it's a kind of same case why we need the Proof of Possession 
> (POP) in RFC2510. Anyway, please note the PII is the double-hashed 
> structure. That is to say, the subject send only intermediate value, 
> H(R || P || SII) to RP without disclosing the SII. Then relying party 
> can calculates H ( R || SIItype || intermediate value) and verifies 
> whether this value is equal to the PII in the certificate. Finally, RP 
> can guess the certificate holder has right certificate even if it 
> doesn't know the value of SII itself.
> 
> Alike the above procedures, the certificate holder should be send R, 
> P, SII and PII in a cert if the RP doesn't have any information about 
> the certificate holder. The rest of the verification is similar to the 
> first two cases.
> 
> In conclusion, PII structure is cryptographically secure and efficient 
> scheme to protect personal information although it seems to be 
> complicated at a glance.
> 
> Best regards,
> Park.
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is 
> not crystal clear.
> 
> It seems that the goal is to allow a relying party to determine 
> whether the subject of a particular certificate is the right person. 
> This is currently difficult since there might be not enough 
> information in the DN and disclosing more information in the DN would 
> be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a 
> real requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification 
> ? If it is a bank account number, is it a number with the right Luhn 
> code computation in it and an existing bank identification number in 
> it ?
> 
> Now the solution is rather complicated and it can be seen that an 
> encryption channel is required. A high level view of the goal(s?) and 
> the advantages of the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that 
> is trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can 
> be revealed by the certifcate holder and thus any relying party to 
> which this information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 

-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sun, 16 Nov 2003 08:15:11 -0500
Importance: Normal
Sender: [email-masked]

Denis:

"R" also helps with adversary finding out some SII when an off-line,
exhaustive dictionary attack is conducted.  With "R" in there, the adversary
has to attack each certificate.  Without "R", the adversary can try random
SII and if it matches a certificate, he has accomplished something.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, November 14, 2003 4:32 AM
To: Jongwook, Park
Cc: [email-masked]; [email-masked]; Russ Housley; [email-masked]; Bill
Burr; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01

Park,

Thank you for the explanations.

> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally,
> the DN in the 'subject' or 'subjectAltName' extension must be unique 
> for each person. However, it is very difficult to identify that the 
> subject of certificates is in fact the right person issued by CA since 
> many people often have the same name.
> 
> To solve the above problem, this document don't use the DN for
> including the non-public data since the information in DN can't meet 
> the requirement and is likely to disclosing private data. 
> Alternatively, this draft proposes the PII(Privacy Identification 
> Information) structure which is encrypted form of any sensitive 
> identifier and finally put into the 'subjectAltName' 'GeneralizedName' 
> 'otherName' field. This way can be regarded as a complementary method 
> for the shortcoming of the DN.
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive
> Identification Identifier and H : Cryptographically secure hash 
> function such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different
> ways in accordance with the RP's security environments. Please refer 
> to the section 5. Example Usage of PII of the draft for details. As a 
> first example, let us suppose the RP already know the SII of the 
> certificate holder via out of band. In this case, certificate holder 
> should send R, P and his certificate containing the PII. Then RP can 
> figure out if the PII in cert and another PII' calculated itself from 
> R, P and SII already obtained are identical or not. It is definitely 
> clear that R and P should be transmitted in a secure channel.

R is only needed, if the SII is too short, to optionnally hide the value of 
SII by preventing guessing attacks. If the SII value is long enough, then R 
is no more needed. So R should be optional.

In the ASN.1 description of the SIM :

  - 1�  the SIItype field is missing,
  - 2�  R should be OPTIONAL,
  - 3�  an indicator should added to say whether or not
        a password is required in the computation.

Note: if neither R and P are present and the SII is long enough, then we 
have the proposal I made in my previous e-mail:

Include in the certificate a hash of "personal information" that can be
revealed by the certificate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis

> For another example, suppose such context where some people don't
> really want to divulge any hint of his sensitive identifier to RPs. 
> Maybe it's a kind of same case why we need the Proof of Possession 
> (POP) in RFC2510. Anyway, please note the PII is the double-hashed 
> structure. That is to say, the subject send only intermediate value, 
> H(R || P || SII) to RP without disclosing the SII. Then relying party 
> can calculates H ( R || SIItype || intermediate value) and verifies 
> whether this value is equal to the PII in the certificate. Finally, RP 
> can guess the certificate holder has right certificate even if it 
> doesn't know the value of SII itself.
> 
> Alike the above procedures, the certificate holder should be send R,
> P, SII and PII in a cert if the RP doesn't have any information about 
> the certificate holder. The rest of the verification is similar to the 
> first two cases.
> 
> In conclusion, PII structure is cryptographically secure and efficient
> scheme to protect personal information although it seems to be 
> complicated at a glance.
> 
> Best regards,
> Park.
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is
> not crystal clear.
> 
> It seems that the goal is to allow a relying party to determine
> whether the subject of a particular certificate is the right person. 
> This is currently difficult since there might be not enough 
> information in the DN and disclosing more information in the DN would 
> be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a
> real requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification
> ? If it is a bank account number, is it a number with the right Luhn 
> code computation in it and an existing bank identification number in 
> it ?
> 
> Now the solution is rather complicated and it can be seen that an
> encryption channel is required. A high level view of the goal(s?) and 
> the advantages of the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that
> is trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can
> be revealed by the certifcate holder and thus any relying party to 
> which this information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 
> 
> 

Date: Sat, 15 Nov 2003 16:18:27 +0200
From: Vadim Fedukovich <[email-masked]>
To: "Jongwook, Park" <[email-masked]>
Cc: "'Denis Pinkas'" <[email-masked]>, [email-masked], [email-masked], Russ Housley <[email-masked]>, [email-masked], Bill Burr <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01
Mail-Followup-To: "Jongwook, Park" <[email-masked]>, 'Denis Pinkas' <[email-masked]>, [email-masked], [email-masked], Russ Housley <[email-masked]>, [email-masked], Bill Burr <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Dear Park,

yes PII suggested makes it unpractical trying to learn protected data
unless the password was disclosured to some party to let it verify
the binding. Once sent out, no control is here anymore and the password
could be sent further to other parties, to prove the binding.
Maybe one can use proofs of knowledge instead to stay in control
of sensitive information. That is, run proofs yourself
using non-X.509 tools and only include proofs-bootstrapping data
in certificates issued.

For example, to prove the number SII is bound to ID certified
one can choose a new fresh random nonce t and send (C, T) to the verifier:
     C = Hash(ID, p, g, (g^{t * SII} mod p))
     T = g^t mod p
where ID is name/locality/country from the certificate and g is
a generator over prime filed (mod p).

The verifier could test that (T^{SII} mod p) corresponds to C, ID, g, p
Given strong hash function and hard discrete logarithm problem such a prof
should be convincing for the verifier.

Yes, the basic prof above could be running by anyone for any ID
so one should include some (private exponent) number in the verification
equation and include corresponding public value (g^{private} mod p)
in the certificate issued.

One can elaborate providing the whole idea looks acceptable

regards,
Vadim

On Fri, Nov 07, 2003 at 09:27:31PM +0900, Jongwook, Park wrote:
> 
> 
> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally, the DN
> in the 'subject' or 'subjectAltName' extension must be unique for each
> person. However, it is very difficult to identify that the subject of
> certificates is in fact the right person issued by CA since many people
> often have the same name. 
> 
> To solve the above problem, this document don't use the DN for including the
> non-public data since the information in DN can't meet the requirement and
> is likely to disclosing private data. Alternatively, this draft proposes the
> PII(Privacy Identification Information) structure which is encrypted form of
> any sensitive identifier and finally put into the 'subjectAltName'
> 'GeneralizedName' 'otherName' field. This way can be regarded as a
> complementary method for the shortcoming of the DN. 
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive
> Identification Identifier and H : Cryptographically secure hash function
> such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different ways in
> accordance with the RP's security environments. Please refer to the section
> 5. Example Usage of PII of the draft for details.
> As a first example, let us suppose the RP already know the SII of the
> certificate holder via out of band. In this case, certificate holder should
> send R, P and his certificate containing the PII. Then RP can figure out if
> the PII in cert and another PII' calculated itself from R, P and SII already
> obtained are identical or not. It is definitely clear that R and P should be
> transmitted in a secure channel. 
> 
> For another example, suppose such context where some people don't really
> want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
> kind of same case why we need the Proof of Possession (POP) in RFC2510.
> Anyway, please note the PII is the double-hashed structure. That is to say,
> the subject send only intermediate value, H(R || P || SII) to RP without
> disclosing the SII. Then relying party can calculates H ( R || SIItype ||
> intermediate value) and verifies whether this value is equal to the PII in
> the certificate. Finally, RP can guess the certificate holder has right
> certificate even if it doesn't know the value of SII itself. 
> 
> Alike the above procedures, the certificate holder should be send R, P, SII
> and PII in a cert if the RP doesn't have any information about the
> certificate holder. The rest of the verification is similar to the first two
> cases. 
> 
> In conclusion, PII structure is cryptographically secure and efficient
> scheme to protect personal information although it seems to be complicated
> at a glance.
> 
> Best regards,
> Park.  
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is not
> crystal clear.
> 
> It seems that the goal is to allow a relying party to determine whether the
> subject of a particular certificate is the right person. This is currently
> difficult since there might be not enough information in the DN and
> disclosing more information in the DN would be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a real
> requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification ?
> If it is a bank account number, is it a number with the right Luhn code
> computation in it and an existing bank identification number in it ?
> 
> Now the solution is rather complicated and it can be seen that an encryption
> channel is required. A high level view of the goal(s?) and the advantages of
> the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that is
> trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can be
> revealed by the certifcate holder and thus any relying party to which this
> information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 

-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz

Date: Fri, 14 Nov 2003 17:07:32 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes
Sender: [email-masked]

Folks,

here are draft minutes from this week's PKIX WG meeting at the 58th IETF.

Please provide comments next week, so that I can submit a final 
version before Thanksgiving.  (that's Nov 27th, for non Turkey 
eaters).

Steve
------------------

PKIX WG Meeting 11/9/03

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

The PKIX WG met once during the 58th IETF. A total of approximately 
73 individuals participated in the meeting.

Agenda review and document status - Tim Polk (NIST)
	There are a number of WG documents in various stages in the 
process. Two RFcs (3628 & 3647) were issued since the last IETF 
meeting.  Three documents (Permanent Identifiers, CMP and CRMF) will 
be revised based on IESG comments. The Logotypes I-D has been revised 
in response to IESG comments and should be approved soon. The Proxy 
Certificates and IP Addresses & AS Identifiers I-Ds are in the hands 
of the IESG. Five documents are close to emerging from the WG. SCVP 
is being revised to reflect WSG last call comments. Attribute 
Certificate Policies is in WG last call, but there is some about re 
support for the document. A straw poll on the document indicated a 
little support for progressing the I-D, but mostly just indifference. 
Qualified certificates will enter WG last call after the meeting. The 
EEC "NIST Curves" I-D and the path building I-D also will be forward 
to the ADs by January.

	Ongoing work items include Subject Identification Method 
(SIM), PK algorithms, LDAP specs, OCSPv2, and progression of 
3279/3280. the only new work item is a name comparison spec (to 
address international name issues), an initial draft of which is 
slated for the Seoul meeting. [slides]

PKIX WG Specifications

SIM - Jongwook Park (KISA) & Tim Polk (NIST)
	This specification is still in early stages of development. 
Current efforts are concentrating on formalizing security goals and 
requirements.  The implementation details are still being revised, 
and in some cases appear as a TBD in the current draft. Unresolved 
issues include where to put the hash value, e.g., as an extension vs. 
as an otherName, and some details of the two-pass hashing function. 
[slides]

RFC 3039bis (Qualified Certificates) - Stefan Santesson (Microsoft)
	The QC document is technically stable and incorporates he 
required changes for 3280 alignment.  Minor issues remain for the 
ASN.1 in the document; the AD has provided clear guidance for 
resolution. Three issues raised on the list (regarding the document 
name, timeline for progression, and its relationship to RFC 3039) 
were also discussed. The WG chairs and the AD indicated that WG Last 
Call is appropriate at this time, and that the new specification 
should obsolete RFC 3039.

Certificate Path Building  - Peter Hesse (Orion Security)
       This document, intended to become an informational RFC, was 
written to provide guidance and recommendations to developers 
building X.509 public-key certification paths within their 
applications, based on experience gained in several contexts. The 
document describes different PKI structures, considerations for 
forward vs. reverse path construction, tree pruning, etc. emphasis on 
value of disallowing repeated name/key combination in a path. 
Guidance is based on experience with various products, but must 
describe processes that are consistent with PKIX RFCs. This is just 
an advisory document, not proscriptive, and so there will be no 
MUSTs, SHOULDS, etc. Plan to release another version of the document 
by the end of this month, then proceed to WG last call. [slides]

OCSPv1 problem - Mike Meyers (Traceroute)
	OCSP has a facility in which a client may include a nonce in 
a request, to detect and reject replays of responses. Unfortunately, 
the RFC did not make perfectly clear that a client MUST reject a 
response that did not include a nonce, if the client included a nonce 
in the request. Similarly, the RFC did not make clear what a server 
should do if it receives a request with a nonce, but is incapable of 
generating a response containing a nonce, i.e., a server that deals 
only with pre-signed responses.
	A straw poll indicated that the vast majority of clients deal 
with these issues properly, but not all. OCSP servers that rely on 
caching do not generate a unique response for each request, so they 
omit nonces.  An error could be returned by a server to indicate the 
inability to respond properly to a request with a nonce, but errors 
are not signed, so this does not address the security concern.
	Russ Housley, the cognizant AD made the following observation 
re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
replay protection is expected. Therefore, the OCSP Responder MUST 
include the same nonce value in the OCSP Response.  If the OCSP 
Client receives an OCSP Response that fails to include the correct 
nonce value, it MUST be rejected."

Liaison/Related Projects

IPsec PKI Profile - Brian Korver (Xythos Software)
	Announcement of a BOF on this topic on Thursday, 9 AM.

Steve Hanna (Sun) - OASIS PKI Obstacles Survey Report
	Steve is the co-chair of the OASIS PKI technical committee. 
Effort is trying to determine obstacles to successful PKI deployment 
and adoption, and to recommend ways to eliminate these obstacles. 
Survey generated 200 responses. Most significant obstacles include:
- lack of application support
- high costs
- complexity, lack of understanding
- interoperability problems

Suggested fixes include:
- free software
- cookbook deployment guidance
- path validation guidance
- too many standards for some function, too general, not enough 
standards for other functions

Action plan now available for public review. [slides]

Path Validation Conformance Tests - Tim Polk [NIST]
	A suite of tests has been developed by NIST and several 
contractors, designed to ensure that products implement RFC 3280 
properly. It is an extensive suite of tests. NIST's goals are to 
encourage vendors to submit products for testing, and for users to 
demand products that pass the tests. Common Criteria Protection 
Profiles have been created, based on these tests, in an effort to 
achieve the goal noted above. These profiles should be validated and 
available for use by the end of 2003.  [slides]

Date: Fri, 14 Nov 2003 14:10:35 -0500
From: Matt Bertapelle <[email-masked]>
To: imc-cml <[email-masked]>, imc-sfl <[email-masked]>, [email-masked]
Subject: v2.3 Certificate Management Library (CML) Now Available
Sender: [email-masked]

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

All,

DigitalNet Government Solutions has delivered the Version 2.3 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.3 CML and documentation is freely available at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.3 CML is described in the v2.3 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.3 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.digitalnet.com/knowledge/snacc_home.htm>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.3 includes the following enhancements (compared to v2.2 
CML release):

1) Added optional bitmask field to the InitSettings_struct to allow the application to specify which CTILs the CML should load during CM_CreateSessionExt().  The application can use this bitmask field rather than pass in a pointer to a valid CTIL::CSM_CtilMgr object in the pTokenObj field of the InitSettings_struct. 

2) Created new C++ function, CML::SetTrustAnchors(), to allow an 
application to specify the trusted public keys for a CML session even 
when the trusted keys don't appear in certificates.

3) Created new C++ class, TrustAnchor, that allows the the application 
to optionally specify additional path validation constraints on each 
trust anchor when calling CML::SetTrustAnchors().  The additional 
constraints that may be specified are the maximum path length to accept 
and the name constraints to apply. 

4) Enhanced the CML cache and session code to be thread-safe.  
Applications may now safely share a single CML session amongst multiple 
threads. 

5) Enhanced CML to check name constraints of email addresses included in 
DNs.

6) Optimized CML path building algorithm for use with the Federal Bridge 
Certification Authority (FBCA) hierarchy.

7) Added two new fields to the C++ CertMatchData structure, canSignCerts 
and canSignCrls.  These new fields enable callers of the 
CML::RequestCerts() C++ function to optionally restrict the certificates 
returned to having those key usage privileges.

8) Fixed bug in the policy mapping processing of path validation.  The 
CML wasn't properly rejecting paths when the special /any-policy/ value 
appeared in a policy mappings extension.

9) Enhanced CRL retrieval and validation code so the CML will now 
retrieve and validate multiple CRLs if necessary to check all revocation 
reasons, even when no distribution point is present in the certificate.  
Previous versions of the CML would only check a single complete CRL if 
no distribution point was present.

10) Added ECDSA-with-SHA256 and ECDSA-with-SHA384 to list of CML 
supported signature algorithms.

v2.3 SRL includes the following enhancements (compared to v2.2 SRL release):

1) Enhanced SRL to perform HTTP and FTP URL retrievals.

2) Removed SRL code that caused some UNIX systems to hang
under certain circumstances when performing an LDAP bind.  With the
removal of the offending code, the SRL now relies completely on the LDAP
library to timeout when an LDAP server is unreachable during a bind
operation.  During testing, some LDAP libraries would take up to 3 minutes
to return from an LDAP bind when the server was down or unreachable.

All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.  

The CML makes calls to an algorithm-independent CTIL API that provides
access to a variety of external crypto libraries. There is a CTIL for
each crypto library that maps the generic CTIL API calls to the
specific calls for that crypto library. DigitalNet provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used
with the CML. The underlying, external crypto libraries are not
distributed as part of the CML software.

The CML has been successfully tested with the v2.3 S/MIME Freeware
Library (SFL) that is freely available from
<http://www.DigitalNet.com/knowledge/sfl_home.htm>.

The CML has been successfully tested with the v2.3 Access Control
Library (ACL) that is freely available to everyone from:
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The CML has been successfully used to build and verify
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)
is a free and openly available test resource provided to
facilitate vendor development of secure, interoperable Public
Key Enabled applications. The CML has been used to successfully
develop and verify the BITS X.509 certification paths available
from <http://bcatest.atl.DigitalNet.com>.

The National Institute of Standards and Technology (NIST) is
providing a standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be
used for testing applications against RFC 2459. The CML was
used to successfully process the NIST test data.

The CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS)
project.

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

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but
please send all messages regarding the CML to the imc-cml mail list
ONLY. Please do not send messages regarding the CML to any of the IETF
mail lists. We will respond to all messages sent to the imc-cml mail
list.

-- 
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
www.DigitalNet.com

--------------040902040404060909050006
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<pre wrap="">All,

DigitalNet Government Solutions has delivered the Version 2.3 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.3 CML and documentation is freely available at:
<a class="moz-txt-link-rfc2396E"
 href="http://www.digitalnet.com/hot/cml_home.htm">&lt;http://www.digitalnet.com/knowledge/cml_home.htm&gt;</a>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.3 CML is described in the v2.3 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.3 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<a class="moz-txt-link-rfc2396E"
 href="http://www.digitalnet.com/hot/snacc_home.htm">&lt;http://www.digitalnet.com/knowledge/snacc_home.htm&gt;</a>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.3 includes the following enhancements (compared to v2.2 
CML release):
<tt>
</tt>1) Added optional bitmask field to the InitSettings_struct to allow the application to specify which CTILs the CML should load during CM_CreateSessionExt().&nbsp; The application can use this bitmask field rather than pass in a pointer to a valid CTIL::CSM_CtilMgr object in the pTokenObj field of the InitSettings_struct. 
</pre>
<tt><o:p></o:p><br>
2) Created new C++ function, CML::SetTrustAnchors(), to
allow an application to specify the trusted public keys for a CML
session even
when the trusted keys don't appear in certificates. <o:p></o:p><br>
<o:p></o:p><br>
3) Created new C++ class, TrustAnchor, that allows the the
application to optionally specify additional path validation
constraints on
each trust anchor when calling CML::SetTrustAnchors().&nbsp; The additional
constraints that may be specified are the maximum path length to accept
and the
name constraints to apply.&nbsp;<o:p></o:p><br>
<o:p></o:p><br>
4) Enhanced the CML cache and session code to be thread-safe.&nbsp;
Applications may now safely share a single CML session amongst multiple
threads.&nbsp;<br>
<o:p></o:p><br>
5) Enhanced CML to check name constraints of email addresses
included in DNs. <o:p></o:p><br>
<o:p></o:p><br>
6) Optimized CML path building algorithm for use with the
Federal Bridge Certification Authority (FBCA) hierarchy.<o:p><br>
</o:p><br>
<o:p></o:p>7) Added two new fields to the C++ CertMatchData structure,
canSignCerts and canSignCrls.&nbsp; These new fields enable callers of the
CML::RequestCerts() C++ function to optionally restrict the
certificates
returned to having those key usage privileges.<o:p></o:p>
<br>
<o:p></o:p><br>
8) Fixed bug in the policy mapping processing of path
validation.&nbsp; The CML wasn't properly rejecting paths when the special <i>any-policy</i>
value appeared in a policy mappings extension.<o:p><br>
</o:p><br>
<o:p></o:p>9) Enhanced CRL retrieval and validation code so the CML
will now retrieve and validate multiple CRLs if necessary to check all
revocation reasons, even when no distribution point is present in the
certificate.&nbsp; Previous versions of the CML would only check a single
complete CRL if no distribution point was present.<o:p><br>
</o:p><br>
<o:p></o:p>10) Added ECDSA-with-SHA256 and ECDSA-with-SHA384 to list of
CML supported signature algorithms.<o:p></o:p>
<br>
<o:p><br>
</o:p><br>
<o:p></o:p>v2.3 SRL includes the following enhancements (compared to
v2.2 SRL release):<br>
</tt>
<pre wrap=""><tt></tt><tt>1) Enhanced SRL to perform HTTP and FTP URL retrievals.<o:p></o:p>
<o:p></o:p>
2) Removed SRL code that caused some UNIX systems to hang
under certain circumstances when performing an LDAP bind.&nbsp; With the
removal of the offending code, the SRL now relies completely on the LDAP
library to timeout when an LDAP server is unreachable during a bind
operation.&nbsp; During testing, some LDAP libraries would take up to 3 minutes
to return from an LDAP bind when the server was down or unreachable.<o:p></o:p>
</tt>

All source code for the CML is being provided at no cost and with no<tt> </tt>financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.  
</pre>
<tt>The CML makes calls to an algorithm-independent CTIL API that
provides<br>
access to a variety of external crypto libraries. There is a CTIL for <br>
each crypto library that maps the generic CTIL API calls to the <br>
specific calls for that crypto library. DigitalNet provides CTILs for<br>
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and <br>
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a <br>
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used <br>
with the CML. The underlying, external crypto libraries are not <br>
distributed as part of the CML software. <br>
<br>
<br>
The CML has been successfully tested with the v2.3 S/MIME Freeware <br>
Library (SFL) that is freely available from <br>
<a class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/sfl_home.htm">&lt;http://www.DigitalNet.com/knowledge/sfl_home.htm&gt;</a>.
<br>
<br>
The CML has been successfully tested with the v2.3 Access Control <br>
Library (ACL) that is freely available to everyone from: <br>
<a class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/acl_home.htm">&lt;http://www.DigitalNet.com/</a><a
 href="http://www.DigitalNet.com/hot/sfl_home.htm"
 class="moz-txt-link-rfc2396E">knowledge/</a><a
 class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/acl_home.htm">acl_home.htm&gt;</a>.<br>
<br>
The CML has been successfully used to build and verify <br>
certificate paths used in the Bridge Certification Authority (BCA)<br>
demonstration which includes cross-certified hierarchical and non-<br>
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)<br>
is a free and openly available test resource provided to <br>
facilitate vendor development of secure, interoperable Public<br>
Key Enabled applications. The CML has been used to successfully<br>
develop and verify the BITS X.509 certification paths available<br>
from <a class="moz-txt-link-rfc2396E"
 href="http://bcatest.atl.DigitalNet.com">&lt;http://bcatest.atl.DigitalNet.com&gt;</a>.
<br>
<br>
The National Institute of Standards and Technology (NIST) is <br>
providing a standard test suite of X.509 certificate paths<br>
<a class="moz-txt-link-rfc2396E"
 href="http://csrc.nist.gov/pki/testing/x509paths.html">&lt;http://csrc.nist.gov/pki/testing/x509paths.html&gt;</a>
that can be<br>
used for testing applications against RFC 2459. The CML was <br>
used to successfully process the NIST test data.<br>
<br>
The CML meets the requirements stated in the SDN.706 Certificate/<br>
CRL Profile required by the U.S. Defense Message System (DMS) <br>
project.<br>
<br>
The Internet Mail Consortium (IMC) has established a CML web page<br>
<a class="moz-txt-link-rfc2396E" href="http://www.imc.org/imc-cml">&lt;http://www.imc.org/imc-cml&gt;</a>
and a CML mail list which is used to: <br>
distribute information regarding CML releases; discuss CML-related <br>
issues; and allow CML users to provide feedback, comments, bug <br>
reports, etc. Subscription information for the imc-cml mailing list <br>
is at the IMC web site listed above. <br>
<br>
All comments regarding the CML source code and documents are welcome. <br>
This CML release announcement was sent to several mail lists, but<br>
please send all messages regarding the CML to the imc-cml mail list<br>
ONLY. Please do not send messages regarding the CML to any of the IETF<br>
mail lists. We will respond to all messages sent to the imc-cml mail <br>
list.</tt>
<pre cols="72" class="moz-signature">-- 
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
<a class="moz-txt-link-abbreviated" href="http://www.DigitalNet.com">www.DigitalNet.com</a></pre>
</body>
</html>

--------------040902040404060909050006--

Date: Fri, 14 Nov 2003 10:31:47 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Jongwook, Park" <[email-masked]>
CC: [email-masked], [email-masked], Russ Housley <[email-masked]>, [email-masked], Bill Burr <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01
Sender: [email-masked]

Park,

Thank you for the explanations.

> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally, the DN
> in the 'subject' or 'subjectAltName' extension must be unique for each
> person. However, it is very difficult to identify that the subject of
> certificates is in fact the right person issued by CA since many people
> often have the same name. 
> 
> To solve the above problem, this document don't use the DN for including the
> non-public data since the information in DN can't meet the requirement and
> is likely to disclosing private data. Alternatively, this draft proposes the
> PII(Privacy Identification Information) structure which is encrypted form of
> any sensitive identifier and finally put into the 'subjectAltName'
> 'GeneralizedName' 'otherName' field. This way can be regarded as a
> complementary method for the shortcoming of the DN. 
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive
> Identification Identifier and H : Cryptographically secure hash function
> such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different ways in
> accordance with the RP's security environments. Please refer to the section
> 5. Example Usage of PII of the draft for details.
> As a first example, let us suppose the RP already know the SII of the
> certificate holder via out of band. In this case, certificate holder should
> send R, P and his certificate containing the PII. Then RP can figure out if
> the PII in cert and another PII' calculated itself from R, P and SII already
> obtained are identical or not. It is definitely clear that R and P should be
> transmitted in a secure channel. 

R is only needed, if the SII is too short, to optionnally hide the value of 
SII by preventing guessing attacks. If the SII value is long enough, then R 
is no more needed. So R should be optional.

In the ASN.1 description of the SIM :

  - 1�  the SIItype field is missing,
  - 2�  R should be OPTIONAL,
  - 3�  an indicator should added to say whether or not
        a password is required in the computation.

Note: if neither R and P are present and the SII is long enough, then we 
have the proposal I made in my previous e-mail:

Include in the certificate a hash of "personal information" that can be
revealed by the certificate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis

> For another example, suppose such context where some people don't really
> want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
> kind of same case why we need the Proof of Possession (POP) in RFC2510.
> Anyway, please note the PII is the double-hashed structure. That is to say,
> the subject send only intermediate value, H(R || P || SII) to RP without
> disclosing the SII. Then relying party can calculates H ( R || SIItype ||
> intermediate value) and verifies whether this value is equal to the PII in
> the certificate. Finally, RP can guess the certificate holder has right
> certificate even if it doesn't know the value of SII itself. 
> 
> Alike the above procedures, the certificate holder should be send R, P, SII
> and PII in a cert if the RP doesn't have any information about the
> certificate holder. The rest of the verification is similar to the first two
> cases. 
> 
> In conclusion, PII structure is cryptographically secure and efficient
> scheme to protect personal information although it seems to be complicated
> at a glance.
> 
> Best regards,
> Park.  
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is not
> crystal clear.
> 
> It seems that the goal is to allow a relying party to determine whether the
> subject of a particular certificate is the right person. This is currently
> difficult since there might be not enough information in the DN and
> disclosing more information in the DN would be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a real
> requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification ?
> If it is a bank account number, is it a number with the right Luhn code
> computation in it and an existing bank identification number in it ?
> 
> Now the solution is rather complicated and it can be seen that an encryption
> channel is required. A high level view of the goal(s?) and the advantages of
> the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that is
> trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can be
> revealed by the certifcate holder and thus any relying party to which this
> information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 
> 
> 

Date: Thu, 13 Nov 2003 22:35:11 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: Tim Polk <[email-masked]>, IETF-PKIX <[email-masked]>
Subject: [I-D] Revised multi-domain PKI interoperability
Cc: [email-masked]
Sender: [email-masked]

Tim and all,

I revised my personal I-D "Memorandum for multi-domain PKI
interoperability". Sorry for my late announcement.

Major changes are the following:
- Add the figures
    + Structure of multi-domain PKI
    + Each PKI model
- Terminology and Assumptions
    + Modify some terminology
    + Assumptions for Repository
- Define PKI Domain 
    + Add new section
- Modify a definition of some PKI model
    + Cross-Certification model
    + Subordination model
    + Hub model
- Consider for trusted third CA
    + Trusted Third CA in Hub model and Super domain model
- Security Considerations
    + Certificate and CRL Profile
    + Some asymmetric problem

The I-D has already published on IETF repository, and it can be also
obtained from our JNSA web site with the detail ChangeLog.

Please refer the following URLs:
Our website:
    http://www.jnsa.org/mpki/
Newest I-D:
    http://www.jnsa.org/mpki/draft-shimaoka-multidomain-pki-01.txt
ChangeLog:
    http://www.jnsa.org/mpki/ChangeLog-en20031027r1.ppt
Original Presentation on 57thIETF:
    http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html

When I revise some minor issues like typo, I will update to our site.
And next major revise (update it in IETF repository) will be by the end
of December.

If you are interested in this, please let me know.
Thanks in advance for any comments.

Abstract of this I-D is shown as below.

	Title		: Memorandum for multi-domain PKI Interoperability
	Author(s)	: M. Shimaoka
	Filename	: draft-shimaoka-multidomain-pki-01.txt
	Pages		: 26
	Date		: October 2003

===== Abstract =====
This memo is used to share the awareness necessary to deployment of
multi-domain PKI. Scope of this memo is to establish trust
relationship and interoperability between plural PKI domains.  Both
single-domain PKI and multi-domain PKI are established by the trust
relationships between Certification Authorities (CAs).  Typical and
primitive PKI models are specified as single-domain PKI.  Multi-
domain PKI established by plural single-domain PKI is categorized as
multi-trust point model and single-trust point model. Multi-trust
point model is based on trust list model, and single-trust point
model is based on cross-certification.
===== Abstract =====

Rgds,
shima

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, "Tim Polk" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 12 Nov 2003 14:18:41 -0600
Importance: Normal
Sender: [email-masked]

Comments on this draft are as follows:

1.  Section 1 para 3;  I object to the phrase "private extensions".
This document does not defined private extensions even if they exist in
the id-pe arc.  These are now public extensions. -- Remove the word
private.

2.  Section 1 para 3: Remove all references to 1993 ASN.1

3.  New section 1.1 is required to be added stating the differences
between this document and 3039

4.  Section 2, para 2:   
 	The text "where the certificate meet some qualification
requirements" should be imported to either "certificates meet" or
"certificate meets"

5.  Section 2, bullet item 3:  Suggest new text of  
 	"-  Definition of usage for the key usage extension in Qualified
      Certificates.."

6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to be
used.  I.E. are we looking for seconds, minutes or hours or just DATE in
the GeneralTime field?

7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If you
have multiple countrys to be listed, should this be a multi-value item
or should there be two distinct attributes? (Alternatively should this
be restricted back to a single attribute with a single value - i.e you
can only list one of your countries of citizenship.)

8.  Section 3.2.4 - This is something that I have no experence with.  If
you look at a jpeg, bitmap or other type if image, who defines what is
considred to be a label and what is considered to be the image data?
What is done in this case about different sized images?

9.  Section 3.2.5.1 - I would like to know the reason that qcstatement-1
has not been updated to a new OID.  This is a new draft document with
some different semantics than 3039.  Are these changes all suffiently
small that a new policy is not needed?

10. Sectin 3.2.5.1 - I have decided to put the predefined statement into
my QC.  After reading this document I understand that what I want
stearts as follows:

	EXTENSION { id-pe-qcStatements,
			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
In this case I don't have asemanticsIdentifier created by the document,
so I must be incoluding the NameRegistrationAuthorities otion.  However
I don't know if what goes here is the pkix working group name or some
other value.

11.  Sectin A.1 - I suggest changing the pretty name to
PKIXqualified88-03 to distinquish from rfc3039.

jim

Date: Tue, 11 Nov 2003 15:04:09 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Last Call: Qualified Certificates
Sender: [email-masked]

I have 4 comments:

1.  In section 2.1, the 1st and 2nd bullets do not have periods.

2.  In section 2.1, 2nd bullet: s/2.3/section 2.3/

3.  In section 3, change the 1st sentence to: "This section defines the 
certificate profile for Qualified Certificates."

4.  ASN.1 syntax is a problem.  Since RFC 3280 does not have a '97 syntax 
module to IMPORT stuff from, I do not see how this document can include a 
'97 syntax.  I think A.2 should be removed.

Russ

Date: Tue, 11 Nov 2003 11:27:44 -0500
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Last Call: Qualified Certificates
Sender: [email-masked]

Folks,

This message initiates working group Last Call for the Qualified Certificates 
specification. This is a two week Last Call and is expected to close November 
25. 

** Do not count on any extension to Last Call!!! **

To keep our efforts coordinated with ETSI's schedule, we need to forward this 
document to the ADs as soon as possible.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-02.txt

The current draft has two known technical issues: (1) the module number for the 
1988 ASN.1 module was incomplete; and (2) the document includes both 1988 and 
1993 ASN.1 syntax.  The module was incomplete, as it did not have a module 
number which prevents compilation.  The 1993 and 1988 syntax ASN.1 were not in 
synch; th 1993 ASN.1 module referenced the 93 ASN.1 syntax from RFC 2459 while 
the 1988 ASN.1 module references RFC 3280.  

Please note that both of these issues have been resolved.  An OID has now been 
assigned, correcting the first issue. The AD has directed the editors to remove 
the '93 ASN.1 module and specify all ASN.1 using the '88 syntax, as in 3280.  
This resolves the second issue.

Thanks,

Tim Polk

From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: request for change in son-of-rfc2633
Date: Mon, 10 Nov 2003 22:41:52 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C3A7DB.D5E6B950
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I have recently run into a problem with signed emails not being able to be
verified, because of the presence of the word "From" in the first columns of
a line of the email message.  This email will serve as an example of this
potential problem.  If your email client sees this message as signed but the
signature is invalid, the next paragraph should start with the word
"From"--see if it has been modified.

>From appearing as the first characters after a blank line will result in
some email delivery agents (such as sendmail or exim) escaping the
word--"From" is replaced with ">From".   The reason for this behavior has to
do with the UNIX mbox mail storage file format.  The mbox format stores
multiple messages in one file, and the messages are separated by the word
"From" as the first characters following a blank line.  Some mail delivery
agents do not have this problem (i.e. Exchange), because they do not store
messages in the mbox format.  Many do, however, resulting in a modification
of the message and the signature being invalidated.

I would like to request that this issue be more directly dealt with in
son-of-RFC2633.  (Currently, it is mentioned in the example MIME-encoded
message, but nowhere in the text.)  One recommendation might be to borrow
from RFC2015 (MIME Security with PGP), which states:
   Though not required, it is generally a good idea to use Quoted-
   Printable encoding in the first step (writing out the data to be
   signed in MIME canonical format) if any of the lines in the data
   begin with "From ", and encode the "F".  This will avoid an MTA
   inserting a ">" in front of the line, thus invalidating the
   signature!

Perhaps this might even be a SHOULD, although I will ask the group to weigh
in on that.

Thanks,

--Peter

------=_NextPart_000_000D_01C3A7DB.D5E6B950
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_000D_01C3A7DB.D5E6B950--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>
Cc: "'pkix group'" <[email-masked]>
Subject: RE: SCVP asn.1 module comments
Date: Mon, 10 Nov 2003 17:41:52 -0600
Importance: Normal
Sender: [email-masked]

Trevor,

I think I already gave you these, but people are talking about a real
soon last call and I want to make sure that they don't get dropped on
the floor.

Jim

Additional ASN.1 module comments:

1.  GeneralNames is defined in PKIX1Implicit88 not PKIX1Explicit88

2.  Personal preference would be to keep UTF8String defined in this
document rather than importing it.

3.  d:\ietf\asn\scvp-13.asn(91) : warning 2004: Field name
'KeyPurposeId' should start with lower letter.

4.  d:\ietf\asn\scvp-13.asn(92) : warning 2004: Field name
'ValidationName' should start with lower letter.

5.  d:\ietf\asn\scvp-13.asn(235) : warning 2004: Field name
'DefaultPolicyID' should start with lower letter.

6.  d:\ietf\asn\scvp-13.asn(285) : error 1019: Type symbol
ValidationAlgorithm never resolved. (--- DUP OF BELOW)

7.  d:\ietf\asn\scvp-13.asn(285) : warning 4001: The imported symbol
'SubjectPublicKeyInfo' is never referenced.

8.  d:\ietf\asn\scvp-13.asn(285) : warning 4002: The symbol
'NameValidationAlg' is never referenced.

9.  Add following text (DUP OF BELOW)
         OCSPResponse FROM OCSP
  {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-ocsp(14)}

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Bryan Pitcher
> Sent: Friday, November 07, 2003 9:32 AM
> To: pkix group
> Subject: SCVP asn.1 module comments
> 
> 
> 
> 
> Hi,
> 
> In reviewing draft-ietf-pkix-scvp-13.txt, I have noticed a
> few issues with the ASN.1 module definition.
> 
> 1.  The constant FullRequestRefUnsuported under ENUMERATION
> SCVPStatusCode is currently defined as 
> 'FullRequestRefUnsuported (51},'.  The '}' character to the 
> right of the 51 should be ')' instead (change the curly brace 
> to a paran).
> 
> 2.  The Query structure has a reference to a structure
> 'ValidationAlgorithm'.  'ValidationAlgorithm isn't imported 
> or defined anywhere in the module.  I assume this is meant to 
> refererence the 'ValidationArg' structure.  
> 
> 3.  The OCSPResponse structure is used in the RevocationInfo
> CHOICE, but not imported.  This is most likely because 
> RFC2560 doesn't define a module identifier in it's ASN.1 
> syntax.  What is generally done in cases like this?
> 
> Thanks,
> Bryan Pitcher
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Mon, 10 Nov 2003 17:38:45 -0500
Importance: Normal
Sender: [email-masked]

I agree

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, November 10, 2003 5:33 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

At 15:20 -0500 11/10/03, Santosh Chokhani wrote:
>Steve:
>
>Do you think there is some benefit to the SIM discussing privacy and 
>linking issues?
>
>I can see that if the same user name (say DN) was issued different 
>certificates with different attributes by the same CA or different CAs, 
>it will be easy to link the identities represented by the various 
>attributes.

I think this is an issue for a CA/RA and for a user. A CA/RA ought 
not facilitate linkage but putting multiple personal identifiers into 
the same cert, or by issuing multiple certs under the same DN, with 
different, personal identifiers. But, it is also the responsibility 
of a user to not request certs from multiple CAs with the same 
subject DN, with distinct personal identifiers.

Steve

Date: Mon, 10 Nov 2003 17:32:56 -0500
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Cc: <[email-masked]>
Sender: [email-masked]

At 15:20 -0500 11/10/03, Santosh Chokhani wrote:
>Steve:
>
>Do you think there is some benefit to the SIM discussing privacy and linking
>issues?
>
>I can see that if the same user name (say DN) was issued different
>certificates with different attributes by the same CA or different CAs, it
>will be easy to link the identities represented by the various attributes.

I think this is an issue for a CA/RA and for a user. A CA/RA ought 
not facilitate linkage but putting multiple personal identifiers into 
the same cert, or by issuing multiple certs under the same DN, with 
different, personal identifiers. But, it is also the responsibility 
of a user to not request certs from multiple CAs with the same 
subject DN, with distinct personal identifiers.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Mon, 10 Nov 2003 15:20:42 -0500
Importance: Normal
Sender: [email-masked]

Steve:

Do you think there is some benefit to the SIM discussing privacy and linking
issues?

I can see that if the same user name (say DN) was issued different
certificates with different attributes by the same CA or different CAs, it
will be easy to link the identities represented by the various attributes.

Should this be a guidance to the subject, RA or both.  It could not be CA
since the CA does not vet these values.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Sunday, November 09, 2003 5:32 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

At 10:12 -0500 11/8/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that putting multiple sensitive attributes in one location is
>inviting trouble.

Sanosh,

The issue the NRC report addresses is not the fact that these 
attributes are "sensitive" pre se. Rather, each attribute of the sort 
you noted is an identifier from a different identity system. The 
report argues that it is a bad idea to bind multiple identity 
attributes in the same cert.

>However, when you look at the details of the protocol, the CA and the
>certificate are not the points of attack since they do not contain 
>sensitive information.  The likely points of attack are the hash, 
>password, subject workstation, relying party workstation, and RA 
>workstation.
>
>Whether you hold single attribute in a certificate or hold multiple
>attributes in various certificates (so that you can present the 
>required attribute to the relying party), the relying party should only 
>see the
>attribute(s) it must.  Thus, putting multiple attributes in the certificate
>is not going to change the relying party workstation vulnerability.

Again, the argument made is the report is not about disclosure of 
these identifies to an RA or CA, but rather the bundling of multiple 
identifiers in a single cert.  The hashes representing the different 
identities, by their combined presence in a single cert, would make 
it easy to link disparate user identities to the same underlying 
individual, a privacy concern.  So, I suggest that we not try to make 
any provision to represent multiple identifies of this sort in a 
single cert.

Steve

Date: Sun, 9 Nov 2003 17:32:24 -0500
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Cc: <[email-masked]>
Sender: [email-masked]

At 10:12 -0500 11/8/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that putting multiple sensitive attributes in one location is
>inviting trouble.

Sanosh,

The issue the NRC report addresses is not the fact that these 
attributes are "sensitive" pre se. Rather, each attribute of the sort 
you noted is an identifier from a different identity system. The 
report argues that it is a bad idea to bind multiple identity 
attributes in the same cert.

>However, when you look at the details of the protocol, the CA and the
>certificate are not the points of attack since they do not contain sensitive
>information.  The likely points of attack are the hash, password, subject
>workstation, relying party workstation, and RA workstation.
>
>Whether you hold single attribute in a certificate or hold multiple
>attributes in various certificates (so that you can present the required
>attribute to the relying party), the relying party should only see the
>attribute(s) it must.  Thus, putting multiple attributes in the certificate
>is not going to change the relying party workstation vulnerability.

Again, the argument made is the report is not about disclosure of 
these identifies to an RA or CA, but rather the bundling of multiple 
identifiers in a single cert.  The hashes representing the different 
identities, by their combined presence in a single cert, would make 
it easy to link disparate user identities to the same underlying 
individual, a privacy concern.  So, I suggest that we not try to make 
any provision to represent multiple identifies of this sort in a 
single cert.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sun, 9 Nov 2003 10:49:49 -0500
Importance: Normal
Sender: [email-masked]

Anders:

If I understand correctly, the SIM approach may be more flexible as more
secure than some of the items listed below since the CA need not hold all
the sensitive information and become a target of attack.

The attractive part of SIM is that even at the RA, sensitive information
needs to be there at the most during registration and after that it is
hashed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: Sunday, November 09, 2003 7:54 AM
To: Santosh Chokhani; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01

Santosh,
I agree with your vulnerability analysis.
The real problem is rather to get broad support for SIM due to the numerous
other ways to achive the same functionality.  Most of the alternatives are
supported by existing standards.

>From an upgraded earlier posting of mine:

Korean citizens (as well as Swedish citizens) have a citizen number that is
more or less "secret" as it contains date-of-birth and gender.  To put this
number in clear in a generic ID-certificate would limit the certificate's
usability as only some relying parties (typically government-associated)
need this information.  To cope with this, you propose a method where a user
in a safe and selective way can transfer this number to an RP that can
verify its authenticity.

Actually the scope of this problem touches a more fundamental issue that I
have spent some time studying: How to combine PKI with "information"
concering the subject.   Therefore, I took the liberty to describe some
completely different methods to achieve "approximately" the same goal.

FINLAND'S SOLUTION
----------------------------
Assign a unique electronic ID (number) to each citizen and supply this
information together with the semi-secret citizen-ID to the RPs that have
the proper authority to handle the secret ID. The electronic ID has no usage
except in on-line usage using certificates but is still usable even for RPs
that do not have or need the secret ID. 

ON-LINE ASSERTIONS
-----------------------------
The following method allows *any* data to be given to RPs, and without
deploying secrets in certificates:

1. The user surfs to an on-line service that needs some additional CA-
   registered information regarding the user
2. The user is authenticated using SSL/TLS client-authentication 3. The
service automatically redirects the user to a CA URL which is deducted  from
the issuer of the certificate 4. The user is authenticated by the CA using
SSL/TLS client-authentication 5. The CA application informs the user that
"Service XYX wants the following
   user attributes, do you agree?"
6. The user hits OK and is automatically redirected back to the service with

   an SAML "ticket" containing the requested attributes signed by the CA

Although looking complex, it is just a couple of mouse-clicks + two
authentication PIN-code-operations for the user to perform. 

If the RP also saves the received ticket, it will not have to repeat the
request a second time, which makes this scheme both very flexible and
user-friendly.

OFF-LINE ASSERTIONS
----------------------------
A user may also surf to a CA, and after being authenticated, request that
the CA sends a CA-signed message with user-attributes to a selected RP.  To
make this a viable scheme, the user-certificate should contain a unique and
static ID in the CAs issuing-domain, in order to to not have to repeat this
process for each certificate renewal.

AUTHENTICATED RP LOOKUP
--------------------------------------
Another solution is that the service authenticates to the CA and gets this
information directly based on user certificate as input.  This solution is
based on that the CAs must "know" the RPs and their needs which is a
drawback.

MULTIPLE CERTIFICATES
---------------------------------
Multiple client-certificates (with and without the number in clear), is of
course another possible solution that has the advantage that nothing special
has to be built.  Requires a little bit more knowledge on the user's part
though and is entirely static with respect to user-attributes.

cheers,
Anders Rundgren

----- Original Message ----- 
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 08, 2003 16:12
Subject: RE: Comments on draft-ietf-pkix-sim-01

Steve:

I agree that putting multiple sensitive attributes in one location is
inviting trouble.

However, when you look at the details of the protocol, the CA and the
certificate are not the points of attack since they do not contain sensitive
information.  The likely points of attack are the hash, password, subject
workstation, relying party workstation, and RA workstation.

Whether you hold single attribute in a certificate or hold multiple
attributes in various certificates (so that you can present the required
attribute to the relying party), the relying party should only see the
attribute(s) it must.  Thus, putting multiple attributes in the certificate
is not going to change the relying party workstation vulnerability.

Similarly, the subject is likely to use the same workstation for carrying
out the transactions and hence subject workstation threat will not change.

The hash algorithm and passwords could have the same diversity whether the
attributes are vetted in one certificate or multiple certificates.

This leaves the RA workstation threat.  If the RA workstation is used to
enter and say hash the attributes, its security compromise could lead to
compromising a set of attributes rather than a single attributes.  However,
using the current I-D, an RA could vet multiple attributes for the same
subject using a single CA or multiple CAs, resulting in the same
vulnerability.

Thus, as a minimum, the RFC Authors should be encouraged to beef up the
security section to discuss the issue of RA protecting the attributes.

I think the best approach may be to add appropriate caution in the Security
Considerations section, discourage the vetting of multiple attributes by an
RA if the RA system has to process those attributes, but permit the
certificate syntax to carry multiple attributes in case there is a need for
it.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or 
>it goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType 
>in the certificate.  Seems that it could be useful to bind SSN, 
>driver's license, and say credit card number all in one certificate so 
>that different relying parties can use the same certificate.  In that 
>case, SIM syntax needs to change and needs to explicitly include 
>SIIType.  If that were done, there does not appear to be a security 
>problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve

From: "Anders Rundgren" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-sim-01
Date: Sun, 9 Nov 2003 13:53:43 +0100
Sender: [email-masked]

Santosh,
I agree with your vulnerability analysis.
The real problem is rather to get broad support for SIM due to the
numerous other ways to achive the same functionality.  Most of the
alternatives are supported by existing standards.

>From an upgraded earlier posting of mine:

Korean citizens (as well as Swedish citizens) have a citizen number that
is more or less "secret" as it contains date-of-birth and gender.  To put
this number in clear in a generic ID-certificate would limit the certificate's
usability as only some relying parties (typically government-associated)
need this information.  To cope with this, you propose a method where
a user in a safe and selective way can transfer this number to an RP
that can verify its authenticity.

Actually the scope of this problem touches a more fundamental issue that
I have spent some time studying: How to combine PKI with "information"
concering the subject.   Therefore, I took the liberty to describe some
completely different methods to achieve "approximately" the same goal.

FINLAND'S SOLUTION
----------------------------
Assign a unique electronic ID (number) to each citizen and supply this
information together with the semi-secret citizen-ID
to the RPs that have the proper authority to handle the secret ID.
The electronic ID has no usage except in on-line usage using
certificates but is still usable even for RPs that do not have
or need the secret ID. 

ON-LINE ASSERTIONS
-----------------------------
The following method allows *any* data to be given to RPs, and without
deploying secrets in certificates:

1. The user surfs to an on-line service that needs some additional CA-
   registered information regarding the user
2. The user is authenticated using SSL/TLS client-authentication
3. The service automatically redirects the user to a CA URL which is deducted
 from the issuer of the certificate
4. The user is authenticated by the CA using SSL/TLS client-authentication
5. The CA application informs the user that "Service XYX wants the following
   user attributes, do you agree?"
6. The user hits OK and is automatically redirected back to the service with 
   an SAML "ticket" containing the requested attributes signed by the CA

Although looking complex, it is just a couple of mouse-clicks + two
authentication PIN-code-operations for the user to perform. 

If the RP also saves the received ticket, it will not have to repeat the
request a second time, which makes this scheme both very flexible
and user-friendly.

OFF-LINE ASSERTIONS
----------------------------
A user may also surf to a CA, and after being authenticated, request
that the CA sends a CA-signed message with user-attributes to a
selected RP.  To make this a viable scheme, the user-certificate should
contain a unique and static ID in the CAs issuing-domain, in order to
to not have to repeat this process for each certificate renewal.

AUTHENTICATED RP LOOKUP
--------------------------------------
Another solution is that the service authenticates to the CA and gets
this information directly based on user certificate as input.  This
solution is based on that the CAs must "know" the RPs and their
needs which is a drawback.

MULTIPLE CERTIFICATES
---------------------------------
Multiple client-certificates (with and without the number in clear), is of
course another possible solution that has the advantage that nothing
special has to be built.  Requires a little bit more knowledge on the
user's part though and is entirely static with respect to user-attributes.

cheers,
Anders Rundgren

----- Original Message ----- 
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 08, 2003 16:12
Subject: RE: Comments on draft-ietf-pkix-sim-01

Steve:

I agree that putting multiple sensitive attributes in one location is
inviting trouble.

However, when you look at the details of the protocol, the CA and the
certificate are not the points of attack since they do not contain sensitive
information.  The likely points of attack are the hash, password, subject
workstation, relying party workstation, and RA workstation.

Whether you hold single attribute in a certificate or hold multiple
attributes in various certificates (so that you can present the required
attribute to the relying party), the relying party should only see the
attribute(s) it must.  Thus, putting multiple attributes in the certificate
is not going to change the relying party workstation vulnerability.

Similarly, the subject is likely to use the same workstation for carrying
out the transactions and hence subject workstation threat will not change.

The hash algorithm and passwords could have the same diversity whether the
attributes are vetted in one certificate or multiple certificates.

This leaves the RA workstation threat.  If the RA workstation is used to
enter and say hash the attributes, its security compromise could lead to
compromising a set of attributes rather than a single attributes.  However,
using the current I-D, an RA could vet multiple attributes for the same
subject using a single CA or multiple CAs, resulting in the same
vulnerability.

Thus, as a minimum, the RFC Authors should be encouraged to beef up the
security section to discuss the issue of RA protecting the attributes.

I think the best approach may be to add appropriate caution in the Security
Considerations section, discourage the vetting of multiple attributes by an
RA if the RA system has to process those attributes, but permit the
certificate syntax to carry multiple attributes in case there is a need for
it.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or
>it goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType
>in the certificate.  Seems that it could be useful to bind SSN, 
>driver's license, and say credit card number all in one certificate so 
>that different relying parties can use the same certificate.  In that 
>case, SIM syntax needs to change and needs to explicitly include 
>SIIType.  If that were done, there does not appear to be a security 
>problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sat, 8 Nov 2003 10:12:27 -0500
Importance: Normal
Sender: [email-masked]

Steve:

I agree that putting multiple sensitive attributes in one location is
inviting trouble.

However, when you look at the details of the protocol, the CA and the
certificate are not the points of attack since they do not contain sensitive
information.  The likely points of attack are the hash, password, subject
workstation, relying party workstation, and RA workstation.

Whether you hold single attribute in a certificate or hold multiple
attributes in various certificates (so that you can present the required
attribute to the relying party), the relying party should only see the
attribute(s) it must.  Thus, putting multiple attributes in the certificate
is not going to change the relying party workstation vulnerability.

Similarly, the subject is likely to use the same workstation for carrying
out the transactions and hence subject workstation threat will not change.

The hash algorithm and passwords could have the same diversity whether the
attributes are vetted in one certificate or multiple certificates.

This leaves the RA workstation threat.  If the RA workstation is used to
enter and say hash the attributes, its security compromise could lead to
compromising a set of attributes rather than a single attributes.  However,
using the current I-D, an RA could vet multiple attributes for the same
subject using a single CA or multiple CAs, resulting in the same
vulnerability.

Thus, as a minimum, the RFC Authors should be encouraged to beef up the
security section to discuss the issue of RA protecting the attributes.

I think the best approach may be to add appropriate caution in the Security
Considerations section, discourage the vetting of multiple attributes by an
RA if the RA system has to process those attributes, but permit the
certificate syntax to carry multiple attributes in case there is a need for
it.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or
>it goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType
>in the certificate.  Seems that it could be useful to bind SSN, 
>driver's license, and say credit card number all in one certificate so 
>that different relying parties can use the same certificate.  In that 
>case, SIM syntax needs to change and needs to explicitly include 
>SIIType.  If that were done, there does not appear to be a security 
>problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve

Date: Fri, 07 Nov 2003 20:12:14 +0000
From: "D.W.Chadwick" <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>, Steven Legg <[email-masked]>
Subject: LDAP issues
Sender: [email-masked]

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

Dear All

the LDAP work that still needs to be progressed within PKIX is

i) LDAPv3 profile for X.509
ii) LDAPv3 schema and syntaxes for X.509 PKI and PMI attributes (using
component matching)
iii) LDAPv3 schema for PKCs, ACs and CRLs (using attribute
decomposition)
iv) DN strings for use with PKIs
v) subject certificate access extension

The IDs for the first three topics have currently expired but are still
active for the last two. There has been very little discussion on any of
the above since the last meeting, but we do plan to issue updates in due
course (very few changes are now needed to the first three sets of IDs).
Unfortunately I cant be at the next meeting to answer any queries on the
above, but Steven Legg will be present and has kindly offered to field
any questions that are raised. The mailing list can also be used for
those not attending the meeting, or who want everyone to be involved in
the discussions.

regards

david

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------7DAFE0E45C1ADEE80D67E89E
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://sec.isi.salford.ac.uk
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-18752
fn:David Chadwick
end:vcard

--------------7DAFE0E45C1ADEE80D67E89E--

To: =?iso-8859-1?Q?pkix_group?= <[email-masked]>
Subject: SCVP asn.1 module comments
From: =?iso-8859-1?Q?Bryan_Pitcher?= <[email-masked]>
Date: Fri,  7 Nov 2003 16:32:01 +0100
Sender: [email-masked]

Hi,

In reviewing draft-ietf-pkix-scvp-13.txt, I have noticed a few issues
with the ASN.1 module definition.

1.  The constant FullRequestRefUnsuported under ENUMERATION
SCVPStatusCode is currently defined as 'FullRequestRefUnsuported (51},'.
 The '}' character to the right of the 51 should be ')' instead (change
the curly brace to a paran).

2.  The Query structure has a reference to a structure
'ValidationAlgorithm'.  'ValidationAlgorithm isn't imported or defined
anywhere in the module.  I assume this is meant to refererence the
'ValidationArg' structure.  

3.  The OCSPResponse structure is used in the RevocationInfo CHOICE, but
not imported.  This is most likely because RFC2560 doesn't define a
module identifier in it's ASN.1 syntax.  What is generally done in cases
like this?

Thanks,
Bryan Pitcher

Date: Fri, 7 Nov 2003 10:13:33 -0500
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or it
>goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType in
>the certificate.  Seems that it could be useful to bind SSN, driver's
>license, and say credit card number all in one certificate so that different
>relying parties can use the same certificate.  In that case, SIM syntax
>needs to change and needs to explicitly include SIIType.  If that were done,
>there does not appear to be a security problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Fri, 7 Nov 2003 09:49:53 -0500
Importance: Normal
Sender: [email-masked]

Tim and Park:

Some more comments:

2.  It is not clear from the document whether SIM is a new extension or it
goes in the subject alternative name field.

3.  Was there some consideration given to add PII for multiple SIIType in
the certificate.  Seems that it could be useful to bind SSN, driver's
license, and say credit card number all in one certificate so that different
relying parties can use the same certificate.  In that case, SIM syntax
needs to change and needs to explicitly include SIIType.  If that were done,
there does not appear to be a security problem with it.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 9:23 AM
To: [email-masked]'
Subject: RE: Comments on draft-ietf-pkix-sim-01

I agree with Park.  I found the document easy to read and follow.  I did not
find the protocol difficult.  It is also easy to see why there are two
stages of hashing.

The document can use some editing.  I did not note my editorial comments as
I was reading it.

I have only one substantive comment.  The document should address how
SIIType is communicated between the subject and the relying party.  I did
not find a mention of it.  May be I simply missed it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jongwook, Park
Sent: Friday, November 07, 2003 7:28 AM
To: 'Denis Pinkas'
Cc: [email-masked]; [email-masked]; Russ Housley; [email-masked]; Bill
Burr; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

Denis:

I think you catch on the basic idea of this draft exactly. Generally, the DN
in the 'subject' or 'subjectAltName' extension must be unique for each
person. However, it is very difficult to identify that the subject of
certificates is in fact the right person issued by CA since many people
often have the same name. 

To solve the above problem, this document don't use the DN for including the
non-public data since the information in DN can't meet the requirement and
is likely to disclosing private data. Alternatively, this draft proposes the
PII(Privacy Identification Information) structure which is encrypted form of
any sensitive identifier and finally put into the 'subjectAltName'
'GeneralizedName' 'otherName' field. This way can be regarded as a
complementary method for the shortcoming of the DN. 

PII structure is defined as follows :

PII = H(R || SIItype || H (R || P || SII))
where R : 160-bit random number, P : Password, SII : Sensitive
Identification Identifier and H : Cryptographically secure hash function
such as SHA-1, not MD2 or MD5.

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details. As a first example, let us
suppose the RP already know the SII of the certificate holder via out of
band. In this case, certificate holder should send R, P and his certificate
containing the PII. Then RP can figure out if the PII in cert and another
PII' calculated itself from R, P and SII already obtained are identical or
not. It is definitely clear that R and P should be transmitted in a secure
channel. 

For another example, suppose such context where some people don't really
want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
kind of same case why we need the Proof of Possession (POP) in RFC2510.
Anyway, please note the PII is the double-hashed structure. That is to say,
the subject send only intermediate value, H(R || P || SII) to RP without
disclosing the SII. Then relying party can calculates H ( R || SIItype ||
intermediate value) and verifies whether this value is equal to the PII in
the certificate. Finally, RP can guess the certificate holder has right
certificate even if it doesn't know the value of SII itself. 

Alike the above procedures, the certificate holder should be send R, P, SII
and PII in a cert if the RP doesn't have any information about the
certificate holder. The rest of the verification is similar to the first two
cases. 

In conclusion, PII structure is cryptographically secure and efficient
scheme to protect personal information although it seems to be complicated
at a glance.

Best regards,
Park.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01

I have always wondered about the goal of this document, since it is not
crystal clear.

It seems that the goal is to allow a relying party to determine whether the
subject of a particular certificate is the right person. This is currently
difficult since there might be not enough information in the DN and
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ? If
it is a bank account number, is it a number with the right Luhn code
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption
channel is required. A high level view of the goal(s?) and the advantages of
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is
trying to be solved:

Include in the certificate a hash of "personal information" that can be
revealed by the certifcate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Fri, 7 Nov 2003 09:22:31 -0500
Importance: Normal
Sender: [email-masked]

I agree with Park.  I found the document easy to read and follow.  I did not
find the protocol difficult.  It is also easy to see why there are two
stages of hashing.

The document can use some editing.  I did not note my editorial comments as
I was reading it.

I have only one substantive comment.  The document should address how
SIIType is communicated between the subject and the relying party.  I did
not find a mention of it.  May be I simply missed it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jongwook, Park
Sent: Friday, November 07, 2003 7:28 AM
To: 'Denis Pinkas'
Cc: [email-masked]; [email-masked]; Russ Housley; [email-masked]; Bill
Burr; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

Denis:

I think you catch on the basic idea of this draft exactly. Generally, the DN
in the 'subject' or 'subjectAltName' extension must be unique for each
person. However, it is very difficult to identify that the subject of
certificates is in fact the right person issued by CA since many people
often have the same name. 

To solve the above problem, this document don't use the DN for including the
non-public data since the information in DN can't meet the requirement and
is likely to disclosing private data. Alternatively, this draft proposes the
PII(Privacy Identification Information) structure which is encrypted form of
any sensitive identifier and finally put into the 'subjectAltName'
'GeneralizedName' 'otherName' field. This way can be regarded as a
complementary method for the shortcoming of the DN. 

PII structure is defined as follows :

PII = H(R || SIItype || H (R || P || SII))
where R : 160-bit random number, P : Password, SII : Sensitive
Identification Identifier and H : Cryptographically secure hash function
such as SHA-1, not MD2 or MD5.

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details. As a first example, let us
suppose the RP already know the SII of the certificate holder via out of
band. In this case, certificate holder should send R, P and his certificate
containing the PII. Then RP can figure out if the PII in cert and another
PII' calculated itself from R, P and SII already obtained are identical or
not. It is definitely clear that R and P should be transmitted in a secure
channel. 

For another example, suppose such context where some people don't really
want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
kind of same case why we need the Proof of Possession (POP) in RFC2510.
Anyway, please note the PII is the double-hashed structure. That is to say,
the subject send only intermediate value, H(R || P || SII) to RP without
disclosing the SII. Then relying party can calculates H ( R || SIItype ||
intermediate value) and verifies whether this value is equal to the PII in
the certificate. Finally, RP can guess the certificate holder has right
certificate even if it doesn't know the value of SII itself. 

Alike the above procedures, the certificate holder should be send R, P, SII
and PII in a cert if the RP doesn't have any information about the
certificate holder. The rest of the verification is similar to the first two
cases. 

In conclusion, PII structure is cryptographically secure and efficient
scheme to protect personal information although it seems to be complicated
at a glance.

Best regards,
Park.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01

I have always wondered about the goal of this document, since it is not
crystal clear.

It seems that the goal is to allow a relying party to determine whether the
subject of a particular certificate is the right person. This is currently
difficult since there might be not enough information in the DN and
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ? If
it is a bank account number, is it a number with the right Luhn code
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption
channel is required. A high level view of the goal(s?) and the advantages of
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is
trying to be solved:

Include in the certificate a hash of "personal information" that can be
revealed by the certifcate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis

From: "Jongwook, Park" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>, "Bill Burr" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Fri, 7 Nov 2003 21:27:31 +0900
Sender: [email-masked]

Denis:

I think you catch on the basic idea of this draft exactly. Generally, the DN
in the 'subject' or 'subjectAltName' extension must be unique for each
person. However, it is very difficult to identify that the subject of
certificates is in fact the right person issued by CA since many people
often have the same name. 

To solve the above problem, this document don't use the DN for including the
non-public data since the information in DN can't meet the requirement and
is likely to disclosing private data. Alternatively, this draft proposes the
PII(Privacy Identification Information) structure which is encrypted form of
any sensitive identifier and finally put into the 'subjectAltName'
'GeneralizedName' 'otherName' field. This way can be regarded as a
complementary method for the shortcoming of the DN. 

PII structure is defined as follows :

PII = H(R || SIItype || H (R || P || SII))
where R : 160-bit random number, P : Password, SII : Sensitive
Identification Identifier and H : Cryptographically secure hash function
such as SHA-1, not MD2 or MD5.

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details.
As a first example, let us suppose the RP already know the SII of the
certificate holder via out of band. In this case, certificate holder should
send R, P and his certificate containing the PII. Then RP can figure out if
the PII in cert and another PII' calculated itself from R, P and SII already
obtained are identical or not. It is definitely clear that R and P should be
transmitted in a secure channel. 

For another example, suppose such context where some people don't really
want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
kind of same case why we need the Proof of Possession (POP) in RFC2510.
Anyway, please note the PII is the double-hashed structure. That is to say,
the subject send only intermediate value, H(R || P || SII) to RP without
disclosing the SII. Then relying party can calculates H ( R || SIItype ||
intermediate value) and verifies whether this value is equal to the PII in
the certificate. Finally, RP can guess the certificate holder has right
certificate even if it doesn't know the value of SII itself. 

Alike the above procedures, the certificate holder should be send R, P, SII
and PII in a cert if the RP doesn't have any information about the
certificate holder. The rest of the verification is similar to the first two
cases. 

In conclusion, PII structure is cryptographically secure and efficient
scheme to protect personal information although it seems to be complicated
at a glance.

Best regards,
Park.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01

I have always wondered about the goal of this document, since it is not
crystal clear.

It seems that the goal is to allow a relying party to determine whether the
subject of a particular certificate is the right person. This is currently
difficult since there might be not enough information in the DN and
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ?
If it is a bank account number, is it a number with the right Luhn code
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption
channel is required. A high level view of the goal(s?) and the advantages of
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is
trying to be solved:

Include in the certificate a hash of "personal information" that can be
revealed by the certifcate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis

Date: Thu, 6 Nov 2003 17:01:20 -0500
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sonof3039-02
Cc: "Denis Pinkas" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

At 21:46 +0000 11/6/03, Stefan Santesson wrote:
>This whole thing is a misunderstanding.
>
>Son of RFC 3039 has yet to go through WG last call.
>It has not been requested to be considered by IESG by the authors.
>
>/Stefan
>

Stefan is right.  My error. I was thinking of the Logotype I-D.

Sorry,

Steve

Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-pkix-sonof3039-02
Date: Thu, 6 Nov 2003 21:56:50 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

Denis,

I see that you have 2 objections and 1 concern,

The document title, key usage and whether it would obsolete RFC 3039.

The title is of minor interest right now. If the community would like to
change it then fine by me. Personally I think it would be a mistake and
not worth the trouble and confusion though.

It MUST however obsolete RFC 3039. We can't have both out there defining
the same extensions, attributes and semantics

Last, this document does NOT deal with the meaning of the key usage
bits. I suggest you take that discussion in relation with ITU X.509 and
RFC 3280 where that is handled.

Recommendations on which key usages to use relative to EU Qualified
Certificates is handled by ETSI TS 102280 and should be discussed there.
I see no value to regulate that in this profile.

I'm sorry that you won't be in Minneapolis for a face to face dialogue
on this.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 6 november 2003 19:11
> To: pkix
> Subject: Comments on draft-ietf-pkix-sonof3039-02
> 
> 
> Tim, Magnus and Stephan,
> 
> I have several MAJOR concerns:
> 
> I wonder if the title of this document is still appropriate:
> "Qualified Certificates Profile"
> 
> The scope is now (extract from the abstract):
> 
>     This document forms a certificate profile, based on RFC 3280, for
>     identity certificates issued to physical persons.
> 
> A more appropriate title would now be:
> 
> "Profile for identity certificates issued to physical persons"
> 
> There has been much confusion from the origin with the title which is
> ambiguous because some people think it is only related to Qualified
> Certificates according to the European Directive on Electronic
Signatures,
> while some others think the opposite. It is now clear that the
document
> does
> not only relate to this European Directive, hence why a change is the
> title
> is needed.
> 
> The wordings "qualified certificates" and "Qualified Certificates"
should
> be
> dropped from the document.
> 
> There is other argument where an implementation conforming to this
profile
> would not conform anymore to this European Directive. The issue
relates to
> the ability to identify the country where the CA is located using the
> country attribute of the DN, if DCs are used.
> 
> The other MAJOR issue has to do with the text about the DS and NR
bits.
> 
> I am asking Steve Kent as co-chair (since Tim Polk is one of the co-
> editors,
> I cannot ask him), to freeze this document until a "clarification"
about
> the
> meaning of these two bits is agreed at the ISO level and reflected in
a
> draft of son-of-RFC3280.
> 
> Finally, since I am also part of the ETSI ESI group dealing with
Qualified
> certificates, I can provide my personal view on this matter: there is
no
> need to issue a new document for RFC 3039. We need some stability.
> 
> So the final question would be whether this proposed document replaces
or
> not RFC 3039. If it gets a different title, then we have no need to
make
> RFC
> 3039 obsolete when/it this document is published.
> 
> Since I will not be at the Minneapolis meeting, I would appreciate
that my
> position is mentionned when this point will be discussed.
> 
> Denis
> 

Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-pkix-sonof3039-02
Date: Thu, 6 Nov 2003 21:46:37 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

This whole thing is a misunderstanding.

Son of RFC 3039 has yet to go through WG last call.
It has not been requested to be considered by IESG by the authors.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 6 november 2003 21:21
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: Comments on draft-ietf-pkix-sonof3039-02
> 
> 
> Denis,
> 
> Your comments are duly noted.  Steve Bellovin and I corresponded on
> this topic earlier today and agreed to wait until after the PKIX WG
> meeting next week before the IEGS would consider the document.
> 
> Stefan, please examine Denis' comments and respond by then.
> 
> Thanks,
> 
> Steve

Date: Thu, 6 Nov 2003 15:20:47 -0500
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-sonof3039-02
Cc: pkix <[email-masked]>
Sender: [email-masked]

Denis,

Your comments are duly noted.  Steve Bellovin and I corresponded on 
this topic earlier today and agreed to wait until after the PKIX WG 
meeting next week before the IEGS would consider the document.

Stefan, please examine Denis' comments and respond by then.

Thanks,

Steve

Date: Thu, 06 Nov 2003 19:40:34 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>
Subject: Comments on draft-ietf-pkix-certpathbuild-01
Sender: [email-masked]

My comments about the way to find out the location of the repositories 
containing elements of the certification path have certainly been taken into 
consideration, ... but I cannot found additional text to reflect this.

Denis.

Date: Thu, 06 Nov 2003 19:38:56 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>
Subject: Comments on draft-ietf-pkix-sim-01
Sender: [email-masked]

I have always wondered about the goal of this document, since it is not 
crystal clear.

It seems that the goal is to allow a relying party to determine whether the 
subject of a particular certificate is the right person. This is currently 
difficult since there might be not enough information in the DN and 
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real 
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ?
If it is a bank account number, is it a number with the right Luhn code 
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption 
channel is required. A high level view of the goal(s?) and the advantages of 
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is 
trying to be solved:

Include in the certificate a hash of "personal information" that can be 
revealed by the certifcate holder and thus any relying party to which this 
information is disclosed can verify it (usually once).

Denis

Date: Thu, 06 Nov 2003 19:10:51 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>
Subject: Comments on draft-ietf-pkix-sonof3039-02
Sender: [email-masked]

Tim, Magnus and Stephan,

I have several MAJOR concerns:

I wonder if the title of this document is still appropriate:
"Qualified Certificates Profile"

The scope is now (extract from the abstract):

    This document forms a certificate profile, based on RFC 3280, for
    identity certificates issued to physical persons.

A more appropriate title would now be:

"Profile for identity certificates issued to physical persons"

There has been much confusion from the origin with the title which is 
ambiguous because some people think it is only related to Qualified 
Certificates according to the European Directive on Electronic Signatures, 
while some others think the opposite. It is now clear that the document does 
not only relate to this European Directive, hence why a change is the title 
is needed.

The wordings "qualified certificates" and "Qualified Certificates" should be 
dropped from the document.

There is other argument where an implementation conforming to this profile 
would not conform anymore to this European Directive. The issue relates to 
the ability to identify the country where the CA is located using the 
country attribute of the DN, if DCs are used.

The other MAJOR issue has to do with the text about the DS and NR bits.

I am asking Steve Kent as co-chair (since Tim Polk is one of the co-editors, 
I cannot ask him), to freeze this document until a "clarification" about the 
meaning of these two bits is agreed at the ISO level and reflected in a 
draft of son-of-RFC3280.

Finally, since I am also part of the ETSI ESI group dealing with Qualified 
certificates, I can provide my personal view on this matter: there is no 
need to issue a new document for RFC 3039. We need some stability.

So the final question would be whether this proposed document replaces or 
not RFC 3039. If it gets a different title, then we have no need to make RFC 
3039 obsolete when/it this document is published.

Since I will not be at the Minneapolis meeting, I would appreciate that my 
position is mentionned when this point will be discussed.

Denis

Date: Thu, 06 Nov 2003 16:47:07 +0100
From: Juergen Brauckmann <[email-masked]>
Organization: TC TrustCenter AG
To: [email-masked]
Subject: Question on use of AIA extension
Sender: [email-masked]

Hi.

I'm trying to understand the semantics of the Authority Info Access 
extension with id-ad-caIssuers access method. The wording in RFC3280 
seems to say that the accessLocation must point to any certificate in 
the cert chain that is at least two levels above the certificate which 
contains the AIA extension:

	"The id-ad-caIssuers OID is used when the additional information
	lists CAs that have issued certificates superior to the CA that
	issued the certificate containing this extension"

However, chapter 6.2 of draft-ietf-pkix-certpathbuild-01.txt states that 
an id-ad-caIssuers may point to a certificate for the issuer of the 
certificate containing the extension.

The question was already raised last year; it would be nice if someone 
could confirm which interpretation is correct.

Thanks a lot,
     Juergen

>     * To: "PKIX" <ietf-pkix@xxxxxxx>
>     * Subject: Question on use of AIA extension
>     * From: "Sarbari Gupta" <sarbari@xxxxxxxxxxxxxxxxxxx>
>     * Date: Fri, 22 Nov 2002 12:32:18 -0500
> 
> I was reviewing the description for the AIA extension in RFC 3280, and
> noticed the following text:
> 
> 	"The id-ad-caIssuers OID is used when the additional information
> 	lists CAs that have issued certificates superior to the CA that
> 	issued the certificate containing this extension"
> 
> The above seems to imply that the AIA extension (if populated) within an EE
> cert, should point to the "grandparent certificate" rather than the "parent
> certificate". Am I interpreting this correctly?
> 
> I was under the impression that CA vendors who make use of this extension
> (such as Microsoft) use the AIA extension to point to the "parent
> certificate". Is this consistent with the RFC 3280 specification?
> 
> Can someone please clarify.
> 
> ==============================
> Sarbari Gupta
> Electrosoft Services, Inc.
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>, "'OSI Directory List'" <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, "Russell Brown" <[email-masked]>
Subject: RE: CRL Certification Path
Date: Thu, 6 Nov 2003 10:38:28 -0500
Importance: Normal
Sender: [email-masked]

Denis:

My reading of X.509 and RFC 3280 is that "the delegation" is referring to
the Indirect CRL Issuer name assertion in the CRL Distribution Point
extension of the certificate.  It does not imply or mandate that the CA
issue a certificate to the CRL issuer.

I would like RFC 3280 editors' view on this.

In terms of delegation to only an upper CA, you are misinterpreting my
text..  The reason I said "whichever terminates first" is to accommodate
your scenario of the certificate issuing CA issuing a certificate to
Indirect CRL issuer.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 10:23 AM
To: Santosh Chokhani
Cc: [email-masked]; 'OSI Directory List'
Subject: Re: CRL Certification Path

Santosh,

> Denis:

> Rules 1 through 3 are only when certificate issuer is the same as the 
> CRL issuer.
> 
> My original post had a single rule for indirect CRL (it emanate from 
> the same trust anchor.  The rule you propose is secure, but much more 
> restrictive and represents a change in both X.509 and RFC 3280.
                                ^^^^^^
I would say a clarification.

RFC 3280 states:

    CRL issuer: an optional system to which a CA delegates the
                publication of certificate revocation lists;

I do not believe that this means an upper CA in the chain, but *the* CA 
which isues certificates and is responsible to provide revocation status 
information using either CRLs or OCSP responses.

RFC 3280 states:

    However, a CA may delegate this responsibility to
    another trusted authority.  Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

When CRLs are used, CAs are also responsible to place the location of the 
CRL issuer in the CRL DP extension for the certificates they issue. It is 
thus not an upper CA that is responsible for this, as your proposed text 
would permit for this.

Your text below is thus not appriopriate.

Denis

 > Neither
> require certificate based delegation of the indirect CRL issuer by the 
> certificate issuer.  This change in the standard may cause backward 
> compatibility problem (I know at least one PKI that does Indirect CRL, 
> but without certificate based delegation by the certificate issuer.  I 
> think the following is appropriate for the Indirect CRL:
> 
> 1.	Certification path for the Indirect CRL shall begin with the same
> trust anchor as the certification path for the certificate whose 
> status is being checked
> 
> 2.	The issuer names in the certification path for the CRL shall match
> one for one with the issuer names in the certification path for the 
> certificate, starting with the trust anchor and ending with the 
> certificate issued to the Indirect CRL issuer or the certificate 
> issuer, whichever terminates first.  During name matching, all 
> self-issued certificates in both paths shall be ignored.
> 
> 3.	Certification path for the CRL shall be valid for at least one of
> the certificate policies acceptable to the relying party.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, November 05, 2003 12:17 PM
> To: Santosh Chokhani
> Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent; [email-masked];
> 'OSI Directory List'
> Subject: Re: CRL Certification Path
> 
> 
> Santosh,
> 
> Thank you for raising the issue.
> 
> I agree that the current text is too vague.
> 
> 
>>Editors of 3280 and X.509:
>>
>>There is a security hole in the X.509 and RFC 3280 certification path 
>>validation for CRL, which can be exploited or result in undesirable 
>>behavior when global name uniqueness among various PKI is not assured.
>>
>>The problem manifests itself when a relying party can not verify 
>>signature on a CRL using the certificate issuer public key and thus 
>>needs to build a certification path for the CRL.  This could occur 
>>when a CA has re-keyed after the certificate whose revocation status 
>>is being checked, was issued.
>>
>>Neither RFC 3280 nor X.509 require that the certification path for the 
>>CRL have some semblance to the certification path for the certificate 
>>whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
>>RFC 3280 states only the following for the certification path for the 
>>CRL:
>>
>>?Obtain and validate the certification path for the complete CRL 
>>issuer.  If a key usage extension is present in the CRL issuer's 
>>certificate, verify that the cRLSign bit is set.?
> 
> 
>>A set of rules along the following lines should be added to RFC 3280
>>and
>>to X.509:
>>
>>      1.      Certification path for the CRL shall begin with the same
>>      trust anchor as the certification path for the certificate whose
>>      status is being checked
>>
>>      2.      The issuer names in the certification path for the CRL
>>      shall match one for one with the issuer names in the certification
>>      path for the certificate, starting with the trust anchor and
>>      ending with the last certificate in the certification path for the
>>      CRL.  During name matching, all self-issued certificates in both
>>      paths shall be ignored.
> 
> 
> This text is not sufficient.
> 
> The CA can nominate a CRL Issuer for the management of the revocation 
> status
> 
> of the certificates that it issues and thus the path is one leg 
> longer,
> since the Issuing CA issues a certificate to nominate the CRL issuer. The 
> text above does not capture this point.
> 
> Denis
> 
> 
> 
> 
>>      3.      Certification path for the CRL shall be valid for at least
>>      one of the certificate policies acceptable to the relying party.
>>
>>Rule 3 above is less restrictive and more appropriate rule would be
>>
>>Alternative rule 3: Certification path for the CRL shall be valid for
>>at
>>least the same certificate policies that the certification path for the 
>>certificate is valid for.  This comparison shall be performed by 
>>converting the policies to the relying party domain.
>>
>>An obvious question comes to mind:
>>
>>      �       What about Indirect CRL?
>>
>>Requiring that the Indirect CRL Issuer be from the trust domain as the 
>>certificate is a good idea and not overly restrictive given that we 
>>can not guarantee global name uniqueness among all the PKIs trusted by 
>>a relying party.
>>
>>Another alternative to all of the above pontification is to require
>>the
>>relying parties to ensure that all trust anchors are constrained to 
>>disjoint name spaces, i.e.,  intersection between the permitted name 
>>spaces for any two trust anchors is null.
>>
>>
>>Santosh Chokhani
>>Orion Security Solutions, Inc.
>>1489 Chain Bridge Road, Suite 300
>>McLean, Virginia 22101
>>(703) 917-0060  Ext. 35(voice)
>>(703) 917-0260 (Fax)
>>[email-masked]
>>Visit our Web site
>>http://www.orionsec.com
>>
>>
> 
> 
> 
> 
> 

Date: Thu, 06 Nov 2003 16:22:57 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked], "'OSI Directory List'" <[email-masked]>
Subject: Re: CRL Certification Path
Sender: [email-masked]

Santosh,

> Denis:

> Rules 1 through 3 are only when certificate issuer is the same as the CRL
> issuer.
> 
> My original post had a single rule for indirect CRL (it emanate from the
> same trust anchor.  The rule you propose is secure, but much more
> restrictive and represents a change in both X.509 and RFC 3280.  
                                ^^^^^^
I would say a clarification.

RFC 3280 states:

    CRL issuer: an optional system to which a CA delegates the
                publication of certificate revocation lists;

I do not believe that this means an upper CA in the chain, but *the* CA 
which isues certificates and is responsible to provide revocation status 
information using either CRLs or OCSP responses.

RFC 3280 states:

    However, a CA may delegate this responsibility to
    another trusted authority.  Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

When CRLs are used, CAs are also responsible to place the location of the 
CRL issuer in the CRL DP extension for the certificates they issue. It is 
thus not an upper CA that is responsible for this, as your proposed text 
would permit for this.

Your text below is thus not appriopriate.

Denis

 > Neither
> require certificate based delegation of the indirect CRL issuer by the
> certificate issuer.  This change in the standard may cause backward
> compatibility problem (I know at least one PKI that does Indirect CRL, but
> without certificate based delegation by the certificate issuer.  I think the
> following is appropriate for the Indirect CRL:
> 
> 1.	Certification path for the Indirect CRL shall begin with the same
> trust anchor as the certification path for the certificate whose status is
> being checked
> 
> 2.	The issuer names in the certification path for the CRL shall match
> one for one with the issuer names in the certification path for the
> certificate, starting with the trust anchor and ending with the certificate
> issued to the Indirect CRL issuer or the certificate issuer, whichever
> terminates first.  During name matching, all self-issued certificates in
> both paths shall be ignored.
> 
> 3.	Certification path for the CRL shall be valid for at least one of
> the certificate policies acceptable to the relying party.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Wednesday, November 05, 2003 12:17 PM
> To: Santosh Chokhani
> Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent; [email-masked];
> 'OSI Directory List'
> Subject: Re: CRL Certification Path
> 
> 
> Santosh,
> 
> Thank you for raising the issue.
> 
> I agree that the current text is too vague.
> 
> 
>>Editors of 3280 and X.509:
>>
>>There is a security hole in the X.509 and RFC 3280 certification path
>>validation for CRL, which can be exploited or result in undesirable 
>>behavior when global name uniqueness among various PKI is not assured.
>>
>>The problem manifests itself when a relying party can not verify
>>signature on a CRL using the certificate issuer public key and thus 
>>needs to build a certification path for the CRL.  This could occur when 
>>a CA has re-keyed after the certificate whose revocation status is being 
>>checked, was issued.
>>
>>Neither RFC 3280 nor X.509 require that the certification path for the
>>CRL have some semblance to the certification path for the certificate 
>>whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
>>RFC 3280 states only the following for the certification path for the CRL:
>>
>>?Obtain and validate the certification path for the complete CRL
>>issuer.  If a key usage extension is present in the CRL issuer's 
>>certificate, verify that the cRLSign bit is set.?
> 
> 
>>A set of rules along the following lines should be added to RFC 3280 
>>and
>>to X.509:
>>
>>      1.      Certification path for the CRL shall begin with the same
>>      trust anchor as the certification path for the certificate whose
>>      status is being checked
>>
>>      2.      The issuer names in the certification path for the CRL
>>      shall match one for one with the issuer names in the certification
>>      path for the certificate, starting with the trust anchor and
>>      ending with the last certificate in the certification path for the
>>      CRL.  During name matching, all self-issued certificates in both
>>      paths shall be ignored.
> 
> 
> This text is not sufficient.
> 
> The CA can nominate a CRL Issuer for the management of the revocation status
> 
> of the certificates that it issues and thus the path is one leg longer, 
> since the Issuing CA issues a certificate to nominate the CRL issuer. The 
> text above does not capture this point.
> 
> Denis
> 
> 
> 
> 
>>      3.      Certification path for the CRL shall be valid for at least
>>      one of the certificate policies acceptable to the relying party.
>>
>>Rule 3 above is less restrictive and more appropriate rule would be
>>
>>Alternative rule 3: Certification path for the CRL shall be valid for 
>>at
>>least the same certificate policies that the certification path for the 
>>certificate is valid for.  This comparison shall be performed by 
>>converting the policies to the relying party domain.
>>
>>An obvious question comes to mind:
>>
>>      �       What about Indirect CRL?
>>
>>Requiring that the Indirect CRL Issuer be from the trust domain as the
>>certificate is a good idea and not overly restrictive given that we can 
>>not guarantee global name uniqueness among all the PKIs trusted by a 
>>relying party.
>>
>>Another alternative to all of the above pontification is to require 
>>the
>>relying parties to ensure that all trust anchors are constrained to 
>>disjoint name spaces, i.e.,  intersection between the permitted name 
>>spaces for any two trust anchors is null.
>>
>>
>>Santosh Chokhani
>>Orion Security Solutions, Inc.
>>1489 Chain Bridge Road, Suite 300
>>McLean, Virginia 22101
>>(703) 917-0060  Ext. 35(voice)
>>(703) 917-0260 (Fax)
>>[email-masked]
>>Visit our Web site
>>http://www.orionsec.com
>>
>>
> 
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: CRL Certification Path
Date: Thu, 6 Nov 2003 08:05:45 -0500
Importance: Normal
Sender: [email-masked]

Thomas:

Generally, trust anchor is revoked using out of band means such as manually
deleting it.  Neither X.509 nor RFC 3280 require revocation status checking
of a trust anchor.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 4:27 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: AW: CRL Certification Path

Denis, Santosh,

there is another reason why the trust anchor for the certificates
verification path should be different to the trust anchor for the CRLs
verification path. What happens when the certificates trust anchor has to be
revoked? If the root (trust anchor) signs the CRL containing its own
certificate the CRLs verification path becomes invalid.

Regards

Thomas Beckmann
 -------------------------------------
 Thomas Beckmann
 Fachgruppenleiter PKI und Trustcenter
 
 SchlumbergerSema  -
 Competence Center Informatik GmbH 
 Lohberg 10
 D-49716 Meppen
 
 Tel:+49 5931-805-242
 Mobil: +49 174 333 62 31  
 Fax: +49 5931-842-242

 EMail: [email-masked]
 Internet: www.SchlumbergerSema.de

> -----Urspr�ngliche Nachricht-----
> Von: Denis Pinkas [mailto:[email-masked]]
> Gesendet: Mittwoch, 5. November 2003 18:17
> An: Santosh Chokhani
> Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent;
> [email-masked]; 'OSI Directory List'
> Betreff: Re: CRL Certification Path
> 
> 
> 
> Santosh,
> 
> Thank you for raising the issue.
> 
> I agree that the current text is too vague.
> 
> > Editors of 3280 and X.509:
> > 
> > There is a security hole in the X.509 and RFC 3280
> certification path
> > validation for CRL, which can be exploited or result in undesirable 
> > behavior when global name uniqueness among various PKI is
> not assured.
> > 
> > The problem manifests itself when a relying party can not verify 
> > signature on a CRL using the certificate issuer public key and thus 
> > needs to build a certification path for the CRL.  This
> could occur when
> > a CA has re-keyed after the certificate whose revocation
> status is being
> > checked, was issued.
> > 
> > Neither RFC 3280 nor X.509 require that the certification
> path for the
> > CRL have some semblance to the certification path for the
> certificate
> > whose status is being checked.  For example, Section 6.3.3
> Step ?f? of
> > RFC 3280 states only the following for the certification
> path for the CRL:
> > 
> > ?Obtain and validate the certification path for the complete CRL 
> > issuer.  If a key usage extension is present in the CRL issuer's 
> > certificate, verify that the cRLSign bit is set.?
> 
> > A set of rules along the following lines should be added to
> RFC 3280 and
> > to X.509:
> > 
> >       1.      Certification path for the CRL shall begin 
> with the same
> >       trust anchor as the certification path for the
> certificate whose
> >       status is being checked
> > 
> >       2.      The issuer names in the certification path for the CRL
> >       shall match one for one with the issuer names in the
> certification
> >       path for the certificate, starting with the trust anchor and
> >       ending with the last certificate in the certification
> path for the
> >       CRL.  During name matching, all self-issued
> certificates in both
> >       paths shall be ignored.
> 
> This text is not sufficient.
> 
> The CA can nominate a CRL Issuer for the management of the revocation 
> status of the certificates that it issues and thus the path is one
> leg longer, 
> since the Issuing CA issues a certificate to nominate the CRL 
> issuer. The 
> text above does not capture this point.
> 
> Denis
> 
> 
> 
> >       3.      Certification path for the CRL shall be valid 
> for at least
> >       one of the certificate policies acceptable to the
> relying party.
> > 
> > Rule 3 above is less restrictive and more appropriate rule would be
> > 
> > Alternative rule 3: Certification path for the CRL shall be
> valid for at
> > least the same certificate policies that the certification
> path for the
> > certificate is valid for.  This comparison shall be performed by 
> > converting the policies to the relying party domain.
> > 
> > An obvious question comes to mind:
> > 
> >       �       What about Indirect CRL?
> > 
> > Requiring that the Indirect CRL Issuer be from the trust
> domain as the
> > certificate is a good idea and not overly restrictive given
> that we can
> > not guarantee global name uniqueness among all the PKIs
> trusted by a
> > relying party.
> > 
> > Another alternative to all of the above pontification is to
> require the
> > relying parties to ensure that all trust anchors are constrained to 
> > disjoint name spaces, i.e.,  intersection between the
> permitted name
> > spaces for any two trust anchors is null.
> > 
> > 
> > Santosh Chokhani
> > Orion Security Solutions, Inc.
> > 1489 Chain Bridge Road, Suite 300
> > McLean, Virginia 22101
> > (703) 917-0060  Ext. 35(voice)
> > (703) 917-0260 (Fax)
> > [email-masked]
> > Visit our Web site
> > http://www.orionsec.com
> > 
> > 
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>, "'OSI Directory List'" <[email-masked]>
Subject: RE: CRL Certification Path
Date: Thu, 6 Nov 2003 08:04:19 -0500
Importance: Normal
Sender: [email-masked]

Denis:

Rules 1 through 3 are only when certificate issuer is the same as the CRL
issuer.

My original post had a single rule for indirect CRL (it emanate from the
same trust anchor.  The rule you propose is secure, but much more
restrictive and represents a change in both X.509 and RFC 3280.  Neither
require certificate based delegation of the indirect CRL issuer by the
certificate issuer.  This change in the standard may cause backward
compatibility problem (I know at least one PKI that does Indirect CRL, but
without certificate based delegation by the certificate issuer.  I think the
following is appropriate for the Indirect CRL:

1.	Certification path for the Indirect CRL shall begin with the same
trust anchor as the certification path for the certificate whose status is
being checked

2.	The issuer names in the certification path for the CRL shall match
one for one with the issuer names in the certification path for the
certificate, starting with the trust anchor and ending with the certificate
issued to the Indirect CRL issuer or the certificate issuer, whichever
terminates first.  During name matching, all self-issued certificates in
both paths shall be ignored.

3.	Certification path for the CRL shall be valid for at least one of
the certificate policies acceptable to the relying party.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, November 05, 2003 12:17 PM
To: Santosh Chokhani
Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent; [email-masked];
'OSI Directory List'
Subject: Re: CRL Certification Path

Santosh,

Thank you for raising the issue.

I agree that the current text is too vague.

> Editors of 3280 and X.509:
> 
> There is a security hole in the X.509 and RFC 3280 certification path
> validation for CRL, which can be exploited or result in undesirable 
> behavior when global name uniqueness among various PKI is not assured.
> 
> The problem manifests itself when a relying party can not verify
> signature on a CRL using the certificate issuer public key and thus 
> needs to build a certification path for the CRL.  This could occur when 
> a CA has re-keyed after the certificate whose revocation status is being 
> checked, was issued.
> 
> Neither RFC 3280 nor X.509 require that the certification path for the
> CRL have some semblance to the certification path for the certificate 
> whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
> RFC 3280 states only the following for the certification path for the CRL:
> 
> ?Obtain and validate the certification path for the complete CRL
> issuer.  If a key usage extension is present in the CRL issuer's 
> certificate, verify that the cRLSign bit is set.?

> A set of rules along the following lines should be added to RFC 3280 
> and
> to X.509:
> 
>       1.      Certification path for the CRL shall begin with the same
>       trust anchor as the certification path for the certificate whose
>       status is being checked
> 
>       2.      The issuer names in the certification path for the CRL
>       shall match one for one with the issuer names in the certification
>       path for the certificate, starting with the trust anchor and
>       ending with the last certificate in the certification path for the
>       CRL.  During name matching, all self-issued certificates in both
>       paths shall be ignored.

This text is not sufficient.

The CA can nominate a CRL Issuer for the management of the revocation status

of the certificates that it issues and thus the path is one leg longer, 
since the Issuing CA issues a certificate to nominate the CRL issuer. The 
text above does not capture this point.

Denis

>       3.      Certification path for the CRL shall be valid for at least
>       one of the certificate policies acceptable to the relying party.
> 
> Rule 3 above is less restrictive and more appropriate rule would be
> 
> Alternative rule 3: Certification path for the CRL shall be valid for 
> at
> least the same certificate policies that the certification path for the 
> certificate is valid for.  This comparison shall be performed by 
> converting the policies to the relying party domain.
> 
> An obvious question comes to mind:
> 
>       �       What about Indirect CRL?
> 
> Requiring that the Indirect CRL Issuer be from the trust domain as the
> certificate is a good idea and not overly restrictive given that we can 
> not guarantee global name uniqueness among all the PKIs trusted by a 
> relying party.
> 
> Another alternative to all of the above pontification is to require 
> the
> relying parties to ensure that all trust anchors are constrained to 
> disjoint name spaces, i.e.,  intersection between the permitted name 
> spaces for any two trust anchors is null.
> 
> 
> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (703) 917-0060  Ext. 35(voice)
> (703) 917-0260 (Fax)
> [email-masked]
> Visit our Web site
> http://www.orionsec.com
> 
> 

From: "=?GB2312?Q?=D0=A1=D0=C2?=" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: 
Date: Thu, 6 Nov 2003 10:36:4 +0800
Sender: [email-masked]

ietf-pkix
	��openssl����֤�飬�ɹ���ֻ����һ�Թ�˽Կ���������Լ�ǩ���Լ��ģ������������ǩ����ʲô������

To: IETF-Announce: ;
Subject: RFC 3647 on Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 05 Nov 2003 11:10:53 -0800
Sender: [email-masked]

--NextPart

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

        RFC 3647

        Title:      Internet X.509 Public Key Infrastructure
                    Certificate Policy and Certification Practices
                    Framework
        Author(s):  S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu
        Status:     Informational
        Date:       November 2003
        Mailbox:    [email-masked], [email-masked],
                    [email-masked], [email-masked],
                    [email-masked]
        Pages:      94
        Characters: 228124
        Obsoletes:  2527

        I-D Tag:    draft-ietf-pkix-ipki-new-rfc2527-02.txt

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

This document presents a framework to assist the writers of
certificate policies or certification practice statements for
participants within public key infrastructures, such as
certification authorities, policy authorities, and communities of
interest that wish to rely on certificates.  In particular, the
framework provides a comprehensive list of topics that potentially
(at the writer's discretion) need to be covered in a certificate
policy or a certification practice statement.  This document
supersedes RFC 2527.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3647

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3628 on Policy Requirements for Time-Stamping Authorities (TSAs)
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 05 Nov 2003 11:08:28 -0800
Sender: [email-masked]

--NextPart

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

        RFC 3628

        Title:      Policy Requirements for Time-Stamping Authorities
                    (TSAs)
        Author(s):  D. Pinkas, N. Pope, J. Ross
        Status:     Informational
        Date:       November 2003
        Mailbox:    [email-masked], [email-masked],
                    [email-masked]
        Pages:      43
        Characters: 92941
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-pr-tsa-05.txt

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

This document defines requirements for a baseline time-stamp policy
for Time-Stamping Authorities (TSAs) issuing time-stamp tokens,
supported by public key certificates, with an accuracy of one
second or better.  A TSA may define its own policy which enhances
the policy defined in this document.  Such a policy shall
incorporate or further constrain the requirements identified in this
document.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3628

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

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

--OtherAccess--
--NextPart--

Date: Wed, 05 Nov 2003 18:17:14 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: Tim Polk <[email-masked]>, Russell Housley <[email-masked]>, Laura Boyer <[email-masked]>, Steve Kent <[email-masked]>, [email-masked], "'OSI Directory List'" <[email-masked]>
Subject: Re: CRL Certification Path
Sender: [email-masked]

Santosh,

Thank you for raising the issue.

I agree that the current text is too vague.

> Editors of 3280 and X.509:
> 
> There is a security hole in the X.509 and RFC 3280 certification path 
> validation for CRL, which can be exploited or result in undesirable 
> behavior when global name uniqueness among various PKI is not assured.
> 
> The problem manifests itself when a relying party can not verify 
> signature on a CRL using the certificate issuer public key and thus 
> needs to build a certification path for the CRL.  This could occur when 
> a CA has re-keyed after the certificate whose revocation status is being 
> checked, was issued.
> 
> Neither RFC 3280 nor X.509 require that the certification path for the 
> CRL have some semblance to the certification path for the certificate 
> whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
> RFC 3280 states only the following for the certification path for the CRL:
> 
> ?Obtain and validate the certification path for the complete CRL 
> issuer.  If a key usage extension is present in the CRL issuer's 
> certificate, verify that the cRLSign bit is set.?

> A set of rules along the following lines should be added to RFC 3280 and 
> to X.509:
> 
>       1.      Certification path for the CRL shall begin with the same
>       trust anchor as the certification path for the certificate whose
>       status is being checked
> 
>       2.      The issuer names in the certification path for the CRL
>       shall match one for one with the issuer names in the certification
>       path for the certificate, starting with the trust anchor and
>       ending with the last certificate in the certification path for the
>       CRL.  During name matching, all self-issued certificates in both
>       paths shall be ignored.

This text is not sufficient.

The CA can nominate a CRL Issuer for the management of the revocation status 
of the certificates that it issues and thus the path is one leg longer, 
since the Issuing CA issues a certificate to nominate the CRL issuer. The 
text above does not capture this point.

Denis

>       3.      Certification path for the CRL shall be valid for at least
>       one of the certificate policies acceptable to the relying party.
> 
> Rule 3 above is less restrictive and more appropriate rule would be
> 
> Alternative rule 3: Certification path for the CRL shall be valid for at 
> least the same certificate policies that the certification path for the 
> certificate is valid for.  This comparison shall be performed by 
> converting the policies to the relying party domain.
> 
> An obvious question comes to mind:
> 
>       �       What about Indirect CRL?
> 
> Requiring that the Indirect CRL Issuer be from the trust domain as the 
> certificate is a good idea and not overly restrictive given that we can 
> not guarantee global name uniqueness among all the PKIs trusted by a 
> relying party.
> 
> Another alternative to all of the above pontification is to require the 
> relying parties to ensure that all trust anchors are constrained to 
> disjoint name spaces, i.e.,  intersection between the permitted name 
> spaces for any two trust anchors is null.
> 
> 
> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (703) 917-0060  Ext. 35(voice)
> (703) 917-0260 (Fax)
> [email-masked]
> Visit our Web site
> http://www.orionsec.com
> 
> 

Date: Tue,  4 Nov 2003 22:40:34 -0500
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: PKIX WG Agenda for 58th IETF
Sender: [email-masked]

PKIX WG (pkix-wg) 

MONDAY, November 10, 2003 1530-1730 

================================= 

CHAIR Stephen Kent <[email-masked]>, Tim Polk <[email-masked]> 

AGENDA 

1. WG Status and Direction 

1.1 Document Status Review [Tim Polk (NIST)] 

       The working group has a number of Internet-Drafts.  Many 
       documents are with the ADs or in various stages of WG Last Call. 
       Several others are ready for Last Call. (10 min.) 

1.2 Proposed WG Milestones [Tim Polk (NIST)] 

       The working group milestones are out of date.  New milestones are 
       needed; these milestones need to satisfy IESG direction for an orderly 
       closeout of WG activities. (10 min.) 

2. PKIX WG Specifications 

    2.1  Subject Identification Method  [TBD] 

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-01.txt 

       The current SIM draft introduces a number of new parameters. 
       While these parameters add additional complexity, they were 
       required to satisfy the draft's security requirements.  The
       presentation will focus on the security requirements and
       proposed solution. Open issues will also be identified.  (10 min.) 

    2.2 LDAP Schemas, String Values, and more 
                                - Peter Gietz 

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution 
       for LDAP based PKI information distribution.  New drafts will be 
       published soon after this meeting; the presenter will discuss changes 
       that will appear in the new drafts.  (15 min.) 

    2.3 Qualified Certificates             Stefan Santesson 

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-02.txt 

       Work on the QC document has continued in both PKIX and ETSI. 
       At least one more draft is envisioned; this presentation will describe 
       planned updates and propose a path for completion of the QC document. 
       (10 min.) 

    2.4 Certification Path Building        Peter Hesse (Gemini Security) 

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-
01.txt 

       This document was written to provide guidance and 
       recommendations to developers building X.509 public-key certification 
       paths within their applications.  The next draft is aimed for WG Last 
       Call; the presenter will discuss changes since -00 and additional 
       changes projected for the forthcoming -02 draft. (10 min.) 

    2.5  OCSP                               Mike Myers (TraceRoute) 

       http://www.ietf.org/rfc/rfc2560.txt

       A number of issues regarding OCSP have resurfaced on the mailing 
       list.  The presenter will summarize the issues from the mailing 
       list and present a way forward.  (5 min.) 

3. Liaison/Related Projects 

    The following specifications will update the WG on related activities. 

    3.1 OASIS PKI survey                        Steve Hanna (Sun) 

       The OASIS Public Key Infrastructure Technical Committee 
       conducted a web-based survey to identify the key barriers to PKI
       deployment and usage.  The TC is currently developing an Action Plan
       to address these barriers.  The presentation will address the survey 
       results and preview the action plan. (15 min.) 

    3.2 Path Validation Protection Profiles     Tim Polk (NIST) 

       NIST is currently performing the interoperability testing for RFC 3280. 
       One aspect of that effort is the RFC 3280 path validation test suite 
       developed jointly by NIST, DigitalNet, and NSA.  To promote independnet 
       testing based on the test suite, NIST has submitted protection profiles 
       for path validation modules for NIAP validation. (10 min.) 

To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
From: Tom Gindin <[email-masked]>
Date: Tue, 4 Nov 2003 17:56:20 -0500
Sender: [email-masked]

        David:

        Banning sequential ID's and having the issuer calculate the key ID 
doesn't seem to help much.  If the subject CA uses method 1 (in section 
4.2.1.2 of RFC 3280) and the issuer uses method 2, the key ID's won't 
match.  Short of requiring a SINGLE calculation method for CA key ID's, 
there seems to be no substitute for communication - having the subject CA 
include the key ID in the request.
        If we agree that in the general case the subject CA should assign 
its own key ID, how does the issuing CA find out which value that is?  The 
two most usual methods for the subject CA to tell the issuing CA anything 
are probably CRMF and PKCS#10.  In CRMF you can just put the SubjectKeyID 
extension into CertTemplate's Extensions field.    In PKCS#10 the same 
extension goes into the PKCS#9 ExtensionRequest attribute.

                Tom Gindin

"David P. Kemp" <[email-masked]>
Sent by: [email-masked]
10/26/2003 11:36 AM

        To:     [email-masked]
        cc: 
        Subject:        Re: AKI and SKI problem with RFC 3280?

Oops, now I understand the scenario Steve Hanna was referring to:
   1. Subject CA picks it's own AKI using a computation
      technique, assuming issing CAs will use the same value
      for SKI (as they should).
   2. Issuing CA issues a cross-cert with an SKI using a different
      computation technique, blindly assuming that subject CA will
      take what he has been given to use as AKI as if subject were
      a child in issuer's hierarchy.

Sorry, Steve for my rant.  A working system has to have a common
set of assumptions, such as SKIs flow from the top down (works only
for hierarchies), or SKIs flow from the subject CAs to the issuers
(works in any topology), or every CA uses the same SKI computation
technique (works in any topology).  I didn't consider the situation
where the issuing CA and subject CA operate using different concepts
of who does what to whom.  Thanks, Stefan, for pointing out that
some CAs that were designed for use only in hierarchies are being
misused to issue cross certificates.

Dave

Stefan Santesson wrote:

> The problem is that RFC 3280 in practice require a CA, issuing a CA
> certs, to ask the subordinate CA for its preferred SKI rather than
> generating it.
> 
> To my knowledge there is no CA software that has implemented that
> behavior. If I'm not wrong they are all counting on that subordinate CAs
> will adopt the SKI generated by the parent CA, as the AKI placed in
> issued certs.
> 
> This works for strict hierarchical structures but not for generic cross
> certification (such as Bridge CA) unless CAs use the same SKI generation
> algorithm.
> 
> /Stefan
> 
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: [email-masked]
>>Subject: Re: AKI and SKI problem with RFC 3280?
>>
>>
>>Santosh,
>>
>>I agree that Section 4.2.1.2 of 3280 unambiguously states
>>that an "issuing CA" that does not populate SKI with the value
>>of AKI used by the "subject CA" is not compliant.
>>
>>It appeared that Steve Hanna was referring to non-3280-compliant
>>CAs, where
>>   "the CA certificate may have been issued by a CA that uses
>>    a different AKI/SKI computation technique than the CA
>>    who's the subject of the CA certificate."
>>
>>A compliant "subject CA" may have an AKI computation technique,
>>but a compliant "issuing CA" must not have an SKI computation
>>technique for CA certs - it must import the subject CA's AKI.
>>
>>Outside the realm of 3280 compliance, where the situation
>>of N different SKIs might occur and AKI/SKI don't necessarily
>>chain, the chaining problem occurs when two issuing CAs use
>>two different computation techniques to assign SKIs to the
>>subject, *not* when the issuing CA uses a different technique
>>than the subject CA.  The subject CA's techniques for choosing
>>an AKI for itself and SKIs to go in its issued certs is
>>completely irrelevant.
>>
>>Dave
>>
>>
>>Santosh Chokhani wrote:
>>
>>>David:
>>>
>>>Some of us are interpreting 3280 (specifically Section
> 
> 4.2.1.2,Subject
> 
>>Key
>>
>>>Identifier) to state that all N SKI should be the same and match the
> 
> AKI
> 
>>>used by the subject CA in the certificates it issues.  If not, the
> 
> CAs
> 
>>that
>>
>>>do not populate the
>>>SKI, may not be RFC 3280 compliant.
>>>
>>>Thus, your suggestion of the subject CA using one of the SKI is a
> 
> more
> 
>>>liberal interpretation of 3280 and is covered by our interpretation
> 
> of
> 
>>3280.
>>
>>>At the risk of being redundant, if all CAs are 3280 compliant all N
> 
> SKI
> 
>>in N
>>
>>>certificates issued to a CA for the same SPKI X == AKI in all
>>
>>certificates
>>
>>>signed by the CA, where the signature can be verified using X
>>>
>>>-----Original Message-----
>>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: [email-masked]
>>>Subject: Re: AKI and SKI problem with RFC 3280?
>>>
>>>
>>>
>>>Isn't the raison d'etre of AKI/SKI to allow a verifier
>>>to select the correct CA cert when multiple certs of the
>>>same issuer with different public keys are available
>>>(i.e. during rollover)?
>>>
>>>A CA may use any computation technique to populate the
>>>SKI of certs that it issues, but it MUST chain its own
>>>SKI into the AKI of certs that it issues.  Otherwise
>>>what's the point of populating AKI at all?
>>>
>>>The reason AKI/SKI chaining MUST NOT be enforced during
>>>path validation is because one CA could have one
>>>signing public key identified by N different SKIs
>>>in N different certs. (That's a bad thang, and cross-certificates
> 
> should
> 
>>>follow precedent rather than using a different SKI for the same
> 
> public
> 
>>key.)
>>
>>>But the CA MUST choose one of it's N SKIs to use as AKI, not make up
>>
>>some
>>
>>>different N+1th value. If it picks one of the N, then AKI is helpful
>>
>>1/Nth
>>
>>>of the time.  If it picks something else, then AKI can never be
> 
> helpful.
> 
>>>Dave
>>>
>>>
>>>Steve Hanna wrote:
>>>
>>>
>>>
>>>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>>>during path validation. To be more explicit, it's
>>>>NOT true that the SKI of a CA certificate must match
>>>>the AKI of a certificate signed by that CA. Why?
>>>>Because the CA certificate may have been issued by
>>>>a CA that uses a different AKI/SKI computation technique
>>>>than the CA who's the subject of the CA certificate.
>>>
>>>
>>>
>>>
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: "Tim Polk" <[email-masked]>, "Russell Housley" <[email-masked]>, "Laura Boyer" <[email-masked]>
Cc: "Steve Kent" <[email-masked]>, <[email-masked]>, "'OSI Directory List'" <[email-masked]>
Subject: CRL Certification Path
Date: Tue, 4 Nov 2003 10:27:43 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0067_01C3A2BE.4B324EE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Editors of 3280 and X.509:

There is a security hole in the X.509 and RFC 3280 certification path
validation for CRL, which can be exploited or result in undesirable =
behavior
when global name uniqueness among various PKI is not assured.

The problem manifests itself when a relying party can not verify =
signature
on a CRL using the certificate issuer public key and thus needs to build =
a
certification path for the CRL.  This could occur when a CA has re-keyed
after the certificate whose revocation status is being checked, was =
issued.

Neither RFC 3280 nor X.509 require that the certification path for the =
CRL
have some semblance to the certification path for the certificate whose
status is being checked.  For example, Section 6.3.3 Step =93f=94 of RFC =
3280
states only the following for the certification path for the CRL:

=93Obtain and validate the certification path for the complete CRL =
issuer.  If
a key usage extension is present in the CRL issuer's certificate, verify
that the cRLSign bit is set.=94

A set of rules along the following lines should be added to RFC 3280 and =
to
X.509:

	1.	Certification path for the CRL shall begin with the same
trust anchor as the certification path for the certificate whose status =
is
being checked

	2.	The issuer names in the certification path for the CRL shall
match one for one with the issuer names in the certification path for =
the
certificate, starting with the trust anchor and ending with the last
certificate in the certification path for the CRL.  During name =
matching,
all self-issued certificates in both paths shall be ignored.

	3.	Certification path for the CRL shall be valid for at least
one of the certificate policies acceptable to the relying party.

Rule 3 above is less restrictive and more appropriate rule would be

Alternative rule 3: Certification path for the CRL shall be valid for at
least the same certificate policies that the certification path for the
certificate is valid for.  This comparison shall be performed by =
converting
the policies to the relying party domain.

An obvious question comes to mind:

	=A7	What about Indirect CRL?

Requiring that the Indirect CRL Issuer be from the trust domain as the
certificate is a good idea and not overly restrictive given that we can =
not
guarantee global name uniqueness among all the PKIs trusted by a relying
party.

Another alternative to all of the above pontification is to require the
relying parties to ensure that all trust anchors are constrained to =
disjoint
name spaces, i.e.,  intersection between the permitted name spaces for =
any
two trust anchors is null.

Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35(voice)
(703) 917-0260 (Fax)
[email-masked]
Visit our Web site
http://www.orionsec.com

------=_NextPart_000_0067_01C3A2BE.4B324EE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4630.0">
<TITLE>CRL Certification Path</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Editors of 3280 and X.509:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There is a security hole in the X.509 =
and RFC 3280 certification path validation for CRL, which can be =
exploited or result in undesirable behavior when global name uniqueness =
among various PKI is not assured.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The problem manifests itself when a =
relying party can not verify signature on a CRL using the certificate =
issuer public key and thus needs to build a certification path for the =
CRL.&nbsp; This could occur when a CA has re-keyed after the certificate =
whose revocation status is being checked, was issued.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Neither RFC 3280 nor X.509 require that =
the certification path for the CRL have some semblance to the =
certification path for the certificate whose status is being =
checked.&nbsp; For example, Section 6.3.3 Step &#8220;f&#8221; of RFC =
3280 states only the following for the certification path for the =
CRL:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&#8220;Obtain and validate the =
certification path for the complete CRL issuer.&nbsp; If a key usage =
extension is present in the CRL issuer's certificate, verify that the =
cRLSign bit is set.&#8221;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A set of rules along the following =
lines should be added to RFC 3280 and to X.509:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall begin with the same trust anchor as =
the certification path for the certificate whose status is being =
checked</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
issuer names in the certification path for the CRL shall match one for =
one with the issuer names in the certification path for the certificate, =
starting with the trust anchor and ending with the last certificate in =
the certification path for the CRL.&nbsp; During name matching, all =
self-issued certificates in both paths shall be ignored.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall be valid for at least one of the =
certificate policies acceptable to the relying party.</FONT></P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Rule 3 above is less restrictive and =
more appropriate rule would be</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Alternative rule 3: Certification path =
for the CRL shall be valid for at least the same certificate policies =
that the certification path for the certificate is valid for.&nbsp; This =
comparison shall be performed by converting the policies to the relying =
party domain.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">An obvious question comes to =
mind:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">=A7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
What about Indirect CRL?</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Requiring that the Indirect CRL Issuer =
be from the trust domain as the certificate is a good idea and not =
overly restrictive given that we can not guarantee global name =
uniqueness among all the PKIs trusted by a relying party.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Another alternative to all of the above =
pontification is to require the relying parties to ensure that all trust =
anchors are constrained to disjoint name spaces, i.e.,&nbsp; =
intersection between the permitted name spaces for any two trust anchors =
is null.</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Santosh Chokhani</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Orion Security Solutions, Inc.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1489 Chain Bridge Road, Suite =
300</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">McLean, Virginia 22101</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0060</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Arial"> </FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Ext. 35</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">(</FONT><FONT SIZE=3D2 FACE=3D"Arial">voice</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0260</FONT><FONT SIZE=3D2 FACE=3D"Arial"> =
(Fax)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Visit our Web site</FONT>

<BR><A HREF=3D"http://www.orionsec.com"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">http://www.orionsec.com</FONT></U></A>
</P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0067_01C3A2BE.4B324EE0--

From: "Santosh Chokhani" <[email-masked]>
To: "Tim Polk" <[email-masked]>, "Russell Housley" <[email-masked]>, "Laura Boyer" <[email-masked]>
Cc: "Steve Kent" <[email-masked]>, <[email-masked]>, "'OSI Directory List'" <[email-masked]>
Subject: CRL Certification Path
Date: Tue, 4 Nov 2003 10:26:44 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0062_01C3A2BE.3C771930
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Editors of 3280 and X.509:

There is a security hole in the X.509 and RFC 3280 certification path
validation for CRL, which can be exploited or result in undesirable =
behavior
when global name uniqueness among various PKI is not assured.

The problem manifests itself when a relying party can not verify =
signature
on a CRL using the certificate issuer public key and thus needs to build =
a
certification path for the CRL.  This could occur when a CA has re-keyed
after the certificate whose revocation status is being checked, was =
issued.

Neither RFC 3280 nor X.509 require that the certification path for the =
CRL
have some semblance to the certification path for the certificate whose
status is being checked.  For example, Section 6.3.3 Step =93f=94 of RFC =
3280
states only the following for the certification path for the CRL:

=93Obtain and validate the certification path for the complete CRL =
issuer.  If
a key usage extension is present in the CRL issuer's certificate, verify
that the cRLSign bit is set.=94

A set of rules along the following lines should be added to RFC 3280 and =
to
X.509:

	1.	Certification path for the CRL shall begin with the same
trust anchor as the certification path for the certificate whose status =
is
being checked

	2.	The issuer names in the certification path for the CRL shall
match one for one with the issuer names in the certification path for =
the
certificate, starting with the trust anchor and ending with the last
certificate in the certification path for the CRL.  During name =
matching,
all self-issued certificates in both paths shall be ignored.

	3.	Certification path for the CRL shall be valid for at least
one of the certificate policies acceptable to the relying party.

Rule 3 above is less restrictive and more appropriate rule would be

Alternative rule 3: Certification path for the CRL shall be valid for at
least the same certificate policies that the certification path for the
certificate is valid for.  This comparison shall be performed by =
converting
the policies to the relying party domain.

An obvious question comes to mind:

	=A7	What about Indirect CRL?

Requiring that the Indirect CRL Issuer be from the trust domain as the
certificate is a good idea and not overly restrictive given that we can =
not
guarantee global name uniqueness among all the PKIs trusted by a relying
party.

Another alternative to all of the above pontification is to require the
relying parties to ensure that all trust anchors are constrained to =
disjoint
name spaces, i.e.,  intersection between the permitted name spaces for =
any
two trust anchors is null.

Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35(voice)
(703) 917-0260 (Fax)
[email-masked]
Visit our Web site
http://www.orionsec.com

------=_NextPart_000_0062_01C3A2BE.3C771930
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4630.0">
<TITLE>CRL Certification Path</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Editors of 3280 and X.509:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There is a security hole in the X.509 =
and RFC 3280 certification path validation for CRL, which can be =
exploited or result in undesirable behavior when global name uniqueness =
among various PKI is not assured.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The problem manifests itself when a =
relying party can not verify signature on a CRL using the certificate =
issuer public key and thus needs to build a certification path for the =
CRL.&nbsp; This could occur when a CA has re-keyed after the certificate =
whose revocation status is being checked, was issued.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Neither RFC 3280 nor X.509 require that =
the certification path for the CRL have some semblance to the =
certification path for the certificate whose status is being =
checked.&nbsp; For example, Section 6.3.3 Step &#8220;f&#8221; of RFC =
3280 states only the following for the certification path for the =
CRL:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&#8220;Obtain and validate the =
certification path for the complete CRL issuer.&nbsp; If a key usage =
extension is present in the CRL issuer's certificate, verify that the =
cRLSign bit is set.&#8221;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A set of rules along the following =
lines should be added to RFC 3280 and to X.509:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall begin with the same trust anchor as =
the certification path for the certificate whose status is being =
checked</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
issuer names in the certification path for the CRL shall match one for =
one with the issuer names in the certification path for the certificate, =
starting with the trust anchor and ending with the last certificate in =
the certification path for the CRL.&nbsp; During name matching, all =
self-issued certificates in both paths shall be ignored.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall be valid for at least one of the =
certificate policies acceptable to the relying party.</FONT></P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Rule 3 above is less restrictive and =
more appropriate rule would be</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Alternative rule 3: Certification path =
for the CRL shall be valid for at least the same certificate policies =
that the certification path for the certificate is valid for.&nbsp; This =
comparison shall be performed by converting the policies to the relying =
party domain.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">An obvious question comes to =
mind:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">=A7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
What about Indirect CRL?</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Requiring that the Indirect CRL Issuer =
be from the trust domain as the certificate is a good idea and not =
overly restrictive given that we can not guarantee global name =
uniqueness among all the PKIs trusted by a relying party.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Another alternative to all of the above =
pontification is to require the relying parties to ensure that all trust =
anchors are constrained to disjoint name spaces, i.e.,&nbsp; =
intersection between the permitted name spaces for any two trust anchors =
is null.</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Santosh Chokhani</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Orion Security Solutions, Inc.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1489 Chain Bridge Road, Suite =
300</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">McLean, Virginia 22101</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0060</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Arial"> </FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Ext. 35</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">(</FONT><FONT SIZE=3D2 FACE=3D"Arial">voice</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0260</FONT><FONT SIZE=3D2 FACE=3D"Arial"> =
(Fax)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Visit our Web site</FONT>

<BR><A HREF=3D"http://www.orionsec.com"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">http://www.orionsec.com</FONT></U></A>
</P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0062_01C3A2BE.3C771930--

Date: Wed, 5 Nov 2003 03:27:38 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Good certificate renewal practice
Sender: [email-masked]

=?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[email-masked]> writes:

>So I guess that all the earlier-suggested renewal methods are okay.

Yup, if your policy allows it.  For example the answer to the question:

  should we revoke the previous certificate and after which delay?

in my code would be that the cert will get revoked once its replacement is
created since to have two otherwise identical certs existing at the same time
will violate the CA database integrity constraints (the CA transaction
engine's ACID properties won't allow this to happen).  Note that the private
key isn't affected (you can still use it, for example, to decrypt data long
after the cert has expired), only the publicly visible CA statement about the
public portion of the key.

However, that's just one particular interpretation.  Everyone else is free to
apply whatever interpretation they choose.

>In any event is there any PKIX draft, that explicit those renewal policies?
>I'm having a hard time believing that the WG let some much room for personal
>appreciation :)

It was a in-joke, a reference to the fact that anything that no-one can really
agree on is made a policy matter, which means that someone else has to take
care of it.

Peter.

Date: Tue, 4 Nov 2003 23:11:41 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Request change in son-of-rfc2633
Sender: [email-masked]

I wrote:

>Mozilla (and no doubt some others that didn't get any publicity) did the same
>thing, and I'm sure they didn't get asked to do that by customers.

Actually that's not right, I thought Mozilla (or at least some apps that used
the Mozilla/Gecko/NSS/whatever code base) were vulnerable because Konqueror
was vulnerable, but it turns out that this was Konqueror with khtml rather
than with kmozilla, with OpenSSL supplying the crypto.  Apologies for the
mixup.

Before this gets read as "OpenSSL is vulnerable", that isn't the case either.
OpenSSL provides application-defined callbacks that can be used to override
some checks (used to handle, as one source aptly described it, "the mass of
broken certs out there").  Some apps provide callbacks that ignore all errors,
which apparently is what happened here.  Standard OpenSSL doesn't have this
problem.

Peter.

Date: Mon, 03 Nov 2003 14:57:53 -0500
From: Steve Hanna <[email-masked]>
To: PKIX List <[email-masked]>
Subject: Draft PKI Action Plan Posted for Review and Comment
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

The OASIS Public Key Infrastructure Technical Committee
(the OASIS PKI TC) has posted a draft PKI Action Plan for
public review, inviting comments and support from PKI
customers, vendors, experts, and others. This plan is
designed to address obstacles to PKI deployment and usage
identified through surveys conducted earlier this year.

The draft PKI Action Plan is available for review at
http://www.oasis-open.org/committees/pki/pkiactionplan.pdf
The survey results are available at these locations
http://www.oasis-open.org/committees/pki/pkiobstaclesjune2003surveyreport.pdf
http://www.oasis-open.org/committees/pki/pkiobstaclesaugust2003surveyreport.pdf

Comments on the plan should be submitted by clicking the
"Send a Comment" button on the PKI TC's web page at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pki

At the PKIX meeting next week, I will briefly summarize
the survey results and the draft PKI Action Plan.
However, I encourage you to review these documents in
detail and submit your comments to the PKI TC.

Note that the PKI TC recognizes that most of the actions
described in the draft PKI Action Plan must be undertaken
not by the PKI TC, but by others (vendors, standards groups,
users, etc.) and that some of these efforts are already
under way. The PKI TC does not intend to usurp these efforts,
but to serve as a catalyst encouraging and accelerating efforts.

Thanks,

Steve Hanna
OASIS PKI TC Co-chair
--------------msF72986030010465915965733
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

--------------msF72986030010465915965733--

From: "Anders Rundgren" <[email-masked]>
To: =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[email-masked]>, <[email-masked]>
Subject: Re: Good certificate renewal practice
Date: Mon, 3 Nov 2003 08:44:35 +0100
Sender: [email-masked]

I believe this is outside of standards.
But I am sure it should conceptually work as it does for credit-cards,
passports etc.   I.e. you receive (automatically or on your own
responsibility) a new card etc. before the existing has expired.
There are no technical needs for revoking as far as I can see.
In an on-line PKI I would assume that the old certificate would
be replaced by the new one automatically.  But on-line certification
is not standardized, and everyone makes their own "pudding"
and assign their own policy.

>From a recent message of mine:

=============================================
   Practically every piece of client-side Web-PKI, ranging
   from on-line certification support to on-line (web-form)
   signing, is currently entirely vendor-dependent
=============================================

I will check out newpki.org!

Anders

----- Original Message -----
From: "Fr�d�ric Giudicelli" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 03, 2003 05:51
Subject: Good certificate renewal practice

Hello,
After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
PKIs should handle certificates renewal.
Can a user request a renewal even if his/her certificate is not about to
expiry? If yes, should we revoke the previous certificate and after which
delay?
Can a user request a renewal even if his/her certificate has expired?
I'm just lost on how implementing certificate renewal in my PKI.

Thanks,
Fr�d�ric Giudicelli
http://www.newpki.org

From: =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Good certificate renewal practice
Date: Mon, 3 Nov 2003 07:29:45 +0100
Sender: [email-masked]

So I guess that all the earlier-suggested renewal methods are okay.
In any event is there any PKIX draft, that explicit those renewal policies?
I'm having a hard time believing that the WG let some much room for personal
appreciation :)

Fr�d�ric Giudicelli
http://www.newpki.org

(Are you trying to say that you would be rich by now?)

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, November 03, 2003 7:14 AM
Subject: Re: Good certificate renewal practice

> =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[email-masked]> writes:
>
> >After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
> >PKIs should handle certificates renewal.
>
> That's a policy matter.
>
> >Can a user request a renewal even if his/her certificate is not about to
> >expiry?
>
> That's a policy matter.
>
> >If yes, should we revoke the previous certificate and after which delay?
>
> That's a policy matter.
>
> >Can a user request a renewal even if his/her certificate has expired?
>
> Th.... well, you get the idea.
>
> Peter.
>
> (Incidentally, the person who originally suggested the ecumenical/policy
>  comment has since expressed regret that he didn't trademark it or
something
>  :-).

Date: Mon, 3 Nov 2003 19:14:41 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Good certificate renewal practice
Sender: [email-masked]

=?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[email-masked]> writes:

>After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
>PKIs should handle certificates renewal.

That's a policy matter.

>Can a user request a renewal even if his/her certificate is not about to
>expiry?

That's a policy matter.

>If yes, should we revoke the previous certificate and after which delay?

That's a policy matter.

>Can a user request a renewal even if his/her certificate has expired?

Th.... well, you get the idea.

Peter.

(Incidentally, the person who originally suggested the ecumenical/policy
 comment has since expressed regret that he didn't trademark it or something
 :-).

From: =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[email-masked]>
To: <[email-masked]>
Subject: Good certificate renewal practice
Date: Mon, 3 Nov 2003 05:51:22 +0100
Sender: [email-masked]

Hello,
After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
PKIs should handle certificates renewal.
Can a user request a renewal even if his/her certificate is not about to
expiry? If yes, should we revoke the previous certificate and after which
delay?
Can a user request a renewal even if his/her certificate has expired?
I'm just lost on how implementing certificate renewal in my PKI.

Thanks,
Fr�d�ric Giudicelli
http://www.newpki.org

Date: Mon, 3 Nov 2003 16:18:12 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Request change in son-of-rfc2633
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Dale Gustafson <[email-masked]> writes:

>The issues raised re: creative ways to insert a "shim DLL" between a secure
>application and CryptoAPI (or any other security library using the common DLL
>form-factor) are most interesting and apply irrespective of use/non-use of
>SSL client authentication.  Anyone know of other recent work in this same
>area?

I look at it in chapter 6 of my book, "Cryptographic security architecture
design and verification".  There are a million ways to do this under Windows,
you can hijack and subvert pretty much anything you want, from kernel calls
(the kernel entry jump tables are modifiable from user-space) through to
subverting apps in various ways (the coolest one being thread injection, I'm
surprised virii don't use that one more often because you become totally
undetectable with that).  Chapter 6 covers the various implications of this in
more detail (I'm being lazy and just citing the chapter to avoid having to
paraphrase the whole thing here :-).

Peter.

Date: Sun, 02 Nov 2003 20:01:25 -0600
From: Dale Gustafson <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked], Jim Heimberg <[email-masked]>
Subject: Re: Request change in son-of-rfc2633
Sender: [email-masked]

Paul Hoffman / IMC wrote

< ... >

> PCs are vulnerable. This doesn't mean we stop all development of
> things that run on PCs.
>
> (FWIW, the paper can be found at
> <http://www.cs.dartmouth.edu/~sws/papers/keyjack.pdf>.)

Interesting paper, although most secure application designers probably realize
that browser keystores are most often protected only by a user-chosen password
which may be weak or even NULL.

The issues raised re: creative ways to insert a "shim DLL" between a secure
application and CryptoAPI (or any other security library using the common DLL
form-factor) are most interesting and apply irrespective of use/non-use of SSL
client authentication.  Anyone know of other recent work in this same area?

> --Paul Hoffman, Director
> --Internet Mail Consortium

Regards,

Dale Gustafson

From: "Anders Rundgren" <[email-masked]>
To: "Pierre Heuze" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Date: Sat, 1 Nov 2003 11:08:42 +0100
Sender: [email-masked]

Pierre,
We apparently agree on the state of affaires.

Regarding your particular concerns, I am slightly less in agreement
as I see on-line certification being a provider-defined activity.
To in a PKCS #10 client-created packet "ask" for certain DN attributes
does not apply to such scenarios.  It is rather "all-on-the-server".

At least the systems that are rolled out in Europe are definitely
of that type and I think this make sense as well.  PKIX standards
(as well as current browser implementations), where designed for
a "collaborative" environment where the user often is supposed to
know about things like key length etc.

But PKIs for on-line banking and e-Governments (C2G) are
targeted at user groups who essentially know nothing about PKI.

The (mostly Java-written) systems I have seen in these areas are
all designed to hide PKI as much as it is technically possible.
These systems, AFAIK, all take a "complete grip" on the whole
process from on-line certification to on-line (web) signatures.

I don't know exactly where that leaves current PKIX standards
or what to do next though.

To get the browser vendors (which are at least five taking the
mobile dittos also in consideration), to cooperate is a major task.
It might actually be easier to define "the whole thing" (on-line
Web-PKI) from scratch using XML and perform this work in W3C
rather than "tweaking" current standards and existing systems.

My 2 �res at least.

Anders

----- Original Message -----
From: "Pierre Heuze" <[email-masked]>
To: "Stephen Kent" <[email-masked]>; "Jean-Marc Desperrier" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, November 01, 2003 00:29
Subject: RE: Web-PKI Keygen/Certreq Questions

Anders Rundgren wrote:
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
Indeed there isn't a de-facto reference for this, by now you must realize
every PKI/Browser vendors have developed their ownn solution as mentionned
already, but don't forget the many token/smart card providers who also have
come-up with additional solutions. So it's the jungle out there, as any
request in a search engine for "browser certificate request" or similar will
show (cf Stephen's comment do some more homework.)

Stephen Kent wrote:
> both browsers have had facilities for generating an RSA key pair for
> a user, and sending a cert request for years.
Indeed, at least 1998 from my own experience, but surely someone will claim
an earlier date. In practice, it is almost always based on free/liberal use
of PKCS#10; which has raised many interop issues as you all know, to mention
few (signature and extension format).

Jean-Marc Desperrier wrote:
>So, from the point of view of what should be put on a web page to get a
>browser to generate a certificate request, there is no standard.
>This can be considered not to be a valable item of concern for pkix
thought.
Indeed this topic is somewhat out of the scope of PKIX, but few things to
consider:
- Requesting a certificate is one of the most basic operation to be
completed in the PKI world and browser based application have gained a large
acceptance. So it is a valid concern.
- Requesting a certificate is a somewhat complex operation, and the
browser-based solution too often overlooked basic consideration for the sake
of simplicity, the main drawbacks are:
- No authentication, Proof of Possession (having the key pair) is
often taken as valid
        authentication mechanism (sic).
      - No standard way to mandate what certificate profile should be used
to fulfil the request
      - No control of the certificate life-cycle, each request are handled
separately which
        doesn't cater well when certificate need to be renewed, or
re-activated
        after suspension.
The above points are in part covered by various PKIX message format, but to
be honest they haven't gained acceptance (yet?) for browser based operations
and if used they are highly not interoperable (i.e. to say the least no
improvement on the interop side compare to using PKCS#10).

So is it the case that one should refine the standard to restrict the use of
existing messages to cover the above scenario as to achieve greater
interoperability and hence acceptance? To me this seems to be a genuine item
for the PKIX group.

Pierre Heuz�
http://www.cardbase.com

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions

At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience
developing three different CA products a few years ago, all were able
to accept enrollment requests from both browsers, and all major
providers of CA software did so as well. it was a necessary
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC.
if the browser vendors choose to support these, then we have
interoperable solutions as well, but vendors must choose to make use
of them.

Steve

CardBASE Technologies�
Address: BIM House, Crofton Road, Dun Laoghaire, Co Dublin, Ireland
PH: +353-1-2843233  FAX: +353-1-2843220  WEB: http://www.cardbase.com
 ***********************************************************************
This e-mail and any attachment, contains information which is private
and confidential and is intended for the addressee only. If you are not
an addressee, you are not authorised to read, copy or use the e-mail
or any attachments. If you have received this e-mail in error, please
notify the sender by return e-mail and then destroy it.
This message has been swept for viruses by anti-virus software.
***********************************************************************