Subject: Certificate Policy Standardization

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 24 Nov 2003 14:30:13 +0100

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: Russ Housley <[email-masked]>
Date: Mon, 24 Nov 2003 10:56:09 -0500

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

---

From: "todd glassey" <[email-masked]>
Date: Mon, 24 Nov 2003 08:23:16 -0800

----- Original Message -----
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 24, 2003 5:30 AM
Subject: Certificate Policy Standardization

> 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

---

From: Steve Hanna <[email-masked]>
Date: Mon, 24 Nov 2003 11:47:25 -0500

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Nov 2003 12:35:25 -0500

>was supposewdly done under.

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 24 Nov 2003 19:10:19 +0100

>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

---

From: "Hans Nilsson" <[email-masked]>
Date: Mon, 24 Nov 2003 20:39:34 +0100

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

---

From: "Terry Hayes" <[email-masked]>
Date: Mon, 24 Nov 2003 12:08:46 -0800

Stephen Kent wrote on 11/24/2003, 9:35 AM:
> ...

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: Stephen Kent <[email-masked]>
Date: Mon, 24 Nov 2003 17:20:05 -0500

At 12:08 -0800 11/24/03, Terry Hayes wrote:
>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

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 24 Nov 2003 23:42:47 +0100

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

Hans

On

---

From: Joseph Doekbrijder <[email-masked]>
Date: Tue, 25 Nov 2003 09:11:18 +0100

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

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

---

From: Michael Ströder <[email-masked]>
Date: Tue, 25 Nov 2003 08:40:32 +0100

> 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: Richard Levitte - VMS Whacker <[email-masked]>
Date: Tue, 25 Nov 2003 11:39:57 +0100 (CET)

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"

---

From: Michael Ströder <[email-masked]>
Date: Tue, 25 Nov 2003 11:50:00 +0100

Richard Levitte - VMS Whacker wrote:
> 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

But the question raised here was what we will gain with
certificate policy OIDs.

> in me that I lack words to express them (not happy feelings, I can

Guess what would happen with certificate policy OIDs if widely deployed.

> Uhmm, I might be historically clueless here: are policy OIDs really a

It doesn't really matter whether this extension was invented in X.509v3 or PKIX.

Ciao, Michael.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Tue, 25 Nov 2003 12:41:38 +0100 (CET)

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.

-----

---

From: "todd glassey" <[email-masked]>
Date: Mon, 24 Nov 2003 17:56:14 -0800

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 :-)

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Nov 2003 09:43:43 -0500

>its needed, only to whether PKIX is allowed to focus on it.

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: Steve Hanna <[email-masked]>
Date: Tue, 25 Nov 2003 09:41:27 -0500

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Nov 2003 09:51:19 -0500

>Uhmm, I might be historically clueless here: are policy OIDs really a
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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 25 Nov 2003 10:11:59 -0500

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

Ciao, Michael.

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 25 Nov 2003 16:11:57 +0100

>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: "Stephen Kent" <[email-masked]>
Date: Tue, 25 Nov 2003 09:51:19 -0500

Steve

---

From: "Stephen Kent" <[email-masked]>
Date: Tue, 25 Nov 2003 09:43:43 -0500

Todd,

Steve

---

From: "Steve Hanna" <[email-masked]>
Date: Tue, 25 Nov 2003 09:41:27 -0500

Thanks,

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 25 Nov 2003 10:11:59 -0500

Michael:

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

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 25 Nov 2003 16:48:06 +0100

Richard Levitte - VMS Whacker wrote:
> Michael Ströder <[email-masked]> said:
> 
> Granularity,

Even more granularity? ;-)

> and a resolution to the question "can this certificate be

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.

> that all certificates were assumed to be equal under one (unwritten?)

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.

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 10:03:08 +0100

>OID can be used to provide amount of trust the relying party should place in

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: Andreas Mitrakas <[email-masked]>
Date: Wed, 26 Nov 2003 10:31:51 +0100

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.

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 11:15:54 +0100

>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: "Santosh Chokhani" <[email-masked]>
Date: Wed, 26 Nov 2003 06:04:14 -0500

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

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

/a

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 14:30:17 +0100 (CET)

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

-----

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 14:30:06 +0100

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

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

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

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:

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

/a

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 14:52:10 +0100

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:

-----

---

From: jim <[email-masked]>
Date: Wed, 26 Nov 2003 09:19:55 -0500

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

---

From: Andreas Mitrakas <[email-masked]>
Date: Wed, 26 Nov 2003 15:18:12 +0100

> Hello Anders,

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

> 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: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 09:55:40 -0500

>     that it sort of feels "natural"?

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

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)

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.

-----

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)

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

-----

---

From: "Hans Nilsson" <[email-masked]>
Date: Wed, 26 Nov 2003 16:12:53 +0100

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

On
> Sent: Wednesday, November 26, 2003 2:30 PM
> To: [email-masked]
On
> What Michael referred to as "bloat" is not policy identifiers themselves
but

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 10:06:41 -0500

>package support any kind of certificate policy settings?

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

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 26 Nov 2003 12:29:18 -0500

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 19:59:20 +0100

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

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 26 Nov 2003 13:04:42 -0700

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: jim <[email-masked]>
Date: Wed, 26 Nov 2003 14:53:01 -0500

Expensive preferred with mostly multiple is what we hear from our 
potential customer database
Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com

---

From: David Engberg <[email-masked]>
Date: Wed, 26 Nov 2003 17:19:48 -0500

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: "L Williams" <[email-masked]>
Date: Wed, 26 Nov 2003 15:41:57 -0800

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,

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

>>If properly used by the CA and relying party systems, the certificate
policy

Steve

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 27 Nov 2003 00:43:13 +0100 (CET)

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

-----

---

From: "Florian Oelmaier" <[email-masked]>
Date: Thu, 27 Nov 2003 00:54:09 +0100

#### 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!!! ####

>     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).

>     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?".

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

>     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?" 

>     This breakage could also be relieved by relay

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

>     superior grasp of and respect for foundational

[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 

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

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 26 Nov 2003 17:24:45 -0700

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

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

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 26 Nov 2003 17:44:04 -0700

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: "Florian Oelmaier" <[email-masked]>
Date: Thu, 27 Nov 2003 02:33:26 +0100

> I've chosen not to incorporate your well reasoned argument 
> due to my business model.  :)

hehehehe

> 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: "Santosh Chokhani" <[email-masked]>
Date: Thu, 27 Nov 2003 00:25:08 -0400

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

---

From: David Engberg <[email-masked]>
Date: Wed, 26 Nov 2003 23:40:26 -0500

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

---

From: Joseph Doekbrijder <[email-masked]>
Date: Thu, 27 Nov 2003 10:43:22 +0100

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

---

From: Joseph Doekbrijder <[email-masked]>
Date: Thu, 27 Nov 2003 10:53:06 +0100

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:

>>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
>>
>>The current X.509 and RFC 3280 permit you build PKI and applications that
>>    
>>
>do
>  
>
>>selected an entirely different approach.  And that they did this
>>    
>>
>completely
>  
>

---

From: Vadim Fedukovich <[email-masked]>
Date: Thu, 27 Nov 2003 12:07:02 +0200

On Wed, Nov 26, 2003 at 05:24:45PM -0700, Michael Myers wrote:
...
> 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

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 27 Nov 2003 13:01:12 +0100

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

Cheers

Josh

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 06:49:06 -0700

> From: Santosh Chokhani
> Sent: Wednesday, November 26, 2003 9:25 PM
> To: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Mike:
>

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: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 07:18:45 -0700

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

> Sent: Wednesday, November 26, 2003 6:33 PM
> To: 'Michael Myers'; [email-masked]

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 07:33:17 -0700

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

Mike

> From: Michael Myers [mailto:[email-masked]]
> Sent: Thursday, November 27, 2003 7:19 AM
> To: Florian Oelmaier; [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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 27 Nov 2003 11:09:29 -0400

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

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 08:39:47 -0700

> 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: Vadim Fedukovich <[email-masked]>
Date: Thu, 27 Nov 2003 18:16:51 +0200

>      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: David Engberg <[email-masked]>
Date: Thu, 27 Nov 2003 12:57:43 -0500

> affected is still quite manageable.

This sounds good to me.

> 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: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 11:41:03 -0700

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: David Engberg [mailto:[email-masked]]
> Sent: Thursday, November 27, 2003 10:58 AM
> To: Michael Myers
> Cc: [email-masked]

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 27 Nov 2003 10:37:33 -0800

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!  :)

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

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

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

> application context to make the determination whether to reject the 

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

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

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

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

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

> WITH RESPONSES WITHOUT NONCE? ***

(STOP SHOUTING, please.)

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

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

		M.

---

From: David Engberg <[email-masked]>
Date: Thu, 27 Nov 2003 14:24:40 -0500

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:
>>>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
>>
>>>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
>>
>>>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
>>
>>>response containing either "good" or "revoked".  I
>>
>>could accept
>>

---

From: David Engberg <[email-masked]>
Date: Thu, 27 Nov 2003 14:45:57 -0500

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
> 
> 
>>Sent: Thursday, November 27, 2003 12:25 PM
>>To: Michael Myers
>>Cc: [email-masked]
>>>"unknown" in #3.b or #4.  Thus, a plain nonceless
>>
>>response of
>>
>>>"good" or "revoked" is non-conformant, while a
>>
>>caveated response
>>

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 12:41:33 -0700

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 13:31:40 -0700

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

Mike

> Sent: Thursday, November 27, 2003 12:46 PM
> To: Michael Myers
> Cc: [email-masked]
> >>> 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.
> >>>

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 27 Nov 2003 15:02:58 -0800

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

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 28 Nov 2003 00:26:07 +0100

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

> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 9:32 PM
> To: [email-masked]
> If anyone objects to the path forward as discussed below, 
> please speak up now.  Concurrence is equally welcome.
> 
> Mike
> 
> 
> > [mailto:[email-masked]]On Behalf Of David Engberg
> 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
> > >
> > >
> > >>> Does this seem a fair compromise?  Note well it's 
> highly dependent 
> > >>> on cycling v1 at Proposed.
> > >>>
> > >>> Mike
> > >
> > >
> > >
> >
> 
>

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 28 Nov 2003 00:38:13 +0100

Hello Marc,

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

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!

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

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

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 27 Nov 2003 15:53:12 -0800

> secure as using CRLs. And definitely better than not checking revocation

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.

> 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

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

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?

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

---

From: David Engberg <[email-masked]>
Date: Thu, 27 Nov 2003 23:53:30 -0500

Marc Branchaud wrote:

> 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

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)

Anders,

-----

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 10:06:41 -0500

sometimes, yes!

Steve

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)

-----

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 26 Nov 2003 13:04:42 -0700

Colleagues,

Mike

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 14:52:10 +0100

Richard,

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

-----

---

From: jim <[email-masked]>
Date: Wed, 26 Nov 2003 09:19:55 -0500

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

---

From: "Hans Nilsson" <[email-masked]>
Date: Wed, 26 Nov 2003 16:12:53 +0100

Hans

On
verify
valid
do
On
but
completely

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Fri, 28 Nov 2003 09:43:59 -0600

I agree it is a good solution.

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 2:32 PM
> To: [email-masked]

---

From: David Engberg <[email-masked]>
Date: Wed, 26 Nov 2003 17:19:48 -0500

Rationale:

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)

-----

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 26 Nov 2003 17:24:45 -0700

Dave,

Mike

---

From: "Hans Nilsson" <[email-masked]>
Date: Wed, 26 Nov 2003 16:12:53 +0100

Hans

On
verify
valid
do
On
but
completely

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 28 Nov 2003 00:38:13 +0100

Hello Marc,

---

From: jim <[email-masked]>
Date: Wed, 26 Nov 2003 09:19:55 -0500

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 10:06:41 -0500

sometimes, yes!

Steve

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 27 Nov 2003 15:53:12 -0800

M.

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 26 Nov 2003 13:04:42 -0700

Colleagues,

Mike

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)

Anders,

-----

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 14:52:10 +0100

Richard,

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

-----

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 26 Nov 2003 12:29:18 -0500

Michael,

Dave

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 28 Nov 2003 09:51:44 -0800

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.