Subject: Re: Certificate Policy Standardization

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: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 12:33:48 -0500

>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: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 19:31:01 +0100 (CET)

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"

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 28 Nov 2003 09:13:56 +0100

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.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 12:33:48 -0500

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 12:33:48 -0500

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 12:33:48 -0500

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Nov 2003 12:33:48 -0500

Steve