Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Jul 1999 12:03:20 +0100

Hi All,

I'm afraid that I haven't had time to read all the mails
on this , so forgive any repeats, but I have a number
of fairly major problems with this draft.

Starting with the goals:

> - Make it easier for applications to deploy PKI based systems

I'd like some examples of applications that will be deployed with
clients that *only* support scvp - if clients have to be able 
to work in either "full" or "scvp" mode, then scvp just adds 
complexity, and shouldn't be promoted.  To me this certainly 
seems to rule out almost all mainstream Internet applications. 
(I wouldn't regard appealing to possible applications as a 
good motivation - lets not give solutions to problems that 
aren't there yet.)

> - Enable the PKI to be used on low-end devices such as telephones

This seems spurious to me - a lot of the phones we make (being part
of Siemens) already do quite a lot of processing involving ASN.1
and crypto (its called GSM and we've made quite a *lot* of phones), 
they also have some serious DSPs in them, so I'd need convincing that
path processing complexity is such an issue. (Path construction
is a different case, but see below).

OTOH, a position that the entire PKI represented by PKIX is too 
heavy is defensible, (though wrong, I'd say), but presumably 
the draft wouldn't be in PKIX if that were the authors' position.  

> - Allow certralization of administering PKI policies

If this is a goal of the draft, (and I do agree that this is 
needed in a lot of situations), then the proposed solution fails
to meet the goal - if you allow clients to specify all the inputs
to the path validation algorithm and mandate that the servers
process according to 2459 then all you've done is moved the
CPU cycles. (Maybe I'm misreading the draft here though? Or maybe
it doesn't say?)

I also have a quite simple problem with the title: this 
doesn't look any simpler than cert path validation! 
(In fact, I'd be willing to sign a petition that no future
drafts should include the word "simple" in their titles
unless they're less than four pages:-).

However, I do think that one of the problems the draft does try 
to address is a serious problem for PKI end entities - path 
constuction.

On the face of it, there are two main hard issues for PKIX end 
entities - path validation and path constuction. Now, I'd
argue that path validation is by far the better understood 
(by client implementors) and that we should be looking at a 
protocol to help EEs with path construction, not a protocol 
which allows various mixtures of the two.

A protocol to assist with path construction also has much
less impact on security. (Basically, scvp as currently
presented has the potential to nullify a lot of the
security assumptions underlying a lot of deployed 
systems, so I'm quite wary of some aspects of this 
proposal, e.g. root self-certs flying about in unsigned 
messages!)

For help with path construction, I'd like a protocol where 
a client simply sends a cert plus some very constrained 
settings to a server and receives back (what the server 
thinks) is a good looking cert path, plus a reference so 
the client can ask the server later for another path for 
the same request (if the client doesn't like the first path
returned).

Interestingly, path construction is also suitable for
implementation on a server - the fact that it can be 
configured to point at the right LDAP, OCSP, whatever,...
servers and can maintain lots of state means that such
a server could get around all the problems clients have
with the possible existence of multiple (potentially) valid 
paths and sub-paths.

My suggestion then would be to progress along the following
lines:

- split this work: 
	- one part purely for assistance with path construction
	- and one part (or zero:-) to see if remote path validation 
	  can really be made "simple"
- loose lots of the optional fields (go for an 80% solution
  not the full whack:-)
- remove the "tiny" gunk entirely (I just don't buy the
  anti-ASN.1 arguments, we've been here too often already)

Regards,
Stephen.

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 2 Jul 1999 09:23:28 -0500

Hi,

Here are some internet-engineering comments, based on
reading this message on the context of the recent message
flow:

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, July 02, 1999 6:03 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
>
> Hi All,
>

The relationship of SVCP to CMP is very similar to
the motivating relationship between X400 P7 and X400 P3 protocols. In that
messaging environment, the overhead of a full P3 UA was hard
to justify - so message store concept was added, and a supporting
protocol created.

The relationship of SVCP to CMP is very similar to
the motivating relationship between X500 DAP and IETF LDAP protocols. In
that
directory enviornment, the overhead of a full DAP UA was hard
to justify - so a lightweight gateway concept was added, and a
supporting protocol created.

The motivating relationship of SVCP to CMP is very similar to
the relationship between X700 CMIP and IETF SNMP v2 protocols. In that
management environment, the overhead of a full CMIS UA was hard
to justify - so a lightweight management concept was added, and a
supporting protocol created.

It is true, as IETF doctrine suggests, that the simple solution
may actually address 90% of the needs - including security needs; and
the full solution may be less required than professional architects
may suggest. The is much evidence for this.

> is a different case, but see below).

Interoperable PKIX path processing requires PKIX-complying path
contruction, and  both local and remote repository management. Not
all "phones" need be "high-end phones"; a pager accepting a PKIX-signed page
should
not be forced into high-end manufacturing and engineering, if we
are aiming at a manufacturing cost of $5, so a billion Chinese
rural folk can access this Internet technology without requiring
a world bank loan becuase the standards were over-engineered and biased
to the industrial world's infrastructure!

Remember, internet standards should be basically implementable by
a programmer-year. Of course, productization takes more
effort, but we are not here as a vendor-forum... we are
here to address the internet community who want
to interwork and communicate.

> unless they're less than four pages:-).

I think the SNMP example holds here, given it
is simple but also uses BER and a ASN.1-based notation. The full CMIF model
was addressed by the IESG-policy and WG ethic, but reduced, and
a simple to implement protocol was specified.  If we were to here
use any OSI message encoding, Id have us use the SNMP BER Subset
and have it specified in the notation used in
the SNMP RFCs. A hundred implementations of this
already exist; a reusable one even comes free with Windows
and a $50  code sample book.

SNMP experience holds again.  The draft should perhaps address
only the protocol, not the required processing by
the server. There are complex MIBs, and simple MIBs in
the SNMP world. Similarly, there can and should be complex
and simple remote-validation-handlers (RVHs!) RVH
and protocol implemention should be separated, I would agree.
one such RVH is of course, validating that a path meets PKIX-QC -
before the little CEC-flag icon is authorized for display to the user...

> which allows various mixtures of the two.

If PKIX path validation is understood, just as with server-side
SET-PKI and cert-validating wallets, there is no reason why PKI
server-solutions cannot support less-capable and less-managed
clients with the same benefits as that this SET variety brought to that
secure payment environment. (SET deals with all
the same PKI issues as PKIX at a more stringent level
of engineered security, note.) In SET, essentially http
was used to access the server-side PKI-Client. In the IETF
we should use the SVCP direction, rather than once
again over-leverage http in a way which is now contrary
to IESG advice.

> proposal, e.g. root self-certs flying about in unsigned

An initialization facility in the protocol is acceptable. Of course
its risks should be discussed here. Nothing stopped
TLS doing trust-point distribution in unprotected
messages, note. So, there is precedent on the current design.
Inclusion, is indeed arguable, however. SVCP over TLS
is also an approach to do trust-point distribution. Requirement
and mechanism analysis would be useful. Need is obvious...

> the same request (if the client doesn't like the first path

SVCP is not meant to be a profile of ldap tuned to
certification-domain graph searching problems. We should profile
an ldap operation to address this need, if its required. Searching
is what directories are good at. I would expect an SVCP provider
to also in reality provide a high-end PKI-tailored directory
solution, to support other aspects of server-side PKI
management for those clients which require greater amounts
of interoperability, and therefore management support.

> with the possible existence of multiple (potentially) valid

I think we have to be careful of server-side client-state
management.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Jul 1999 17:55:56 +0100

Peter,

Just responding to the major points, not blow-by-blow.

> The relationship of SVCP to CMP ...
[...lots of stuff deleted...]

I'm surprised you compare scvp (or is it SVCP?) to CMP, I saw
it as an alternative to an EE doing its own cert path 
construction and validation. I certainly would never envisage
anyone using CMP as it stands for this functionality.
Correct me if I'm wrong, but the I-D certainly doesn't give
this scvp vs. CMP impression.

> > This seems spurious to me - 
[stuff deleted]

Ok, so it doesn't seem spurious to you, we disagree.
 
> a simple to implement protocol was specified.  
[stuff deleted again]

Is your argument to call this "simpler certificate validation
protocol"? Simpler than what? As fas as I know there is no other
standardised certificate validation protocol (other than in the 
EDIFACT world).

> an ldap operation to address this need, if its required. 

Actually, I can't really see how an ldap operation can do
path construction in general. Be interested in being shown
how it could.

> I think we have to be careful of server-side client-state

True, however, a path constructing server wouldn't managing 
state for a client, its state would rather be a "snapshot" 
of the PKI which is independent of particular clients.

Stephen.

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 06 Jul 1999 10:20:23 -0700

At 09:23 AM 7/2/99 -0500, Peter Williams wrote:

>a programmer-year. Of course, productization takes more effort,
>but we are not here as a vendor-forum... we are here to address
>the internet community who want to interwork and communicate.

I'd like to have that paragraph bronzed, if I may;)

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jul 1999 10:16:58 -0400

While it would be nice if the complexity of implementing an Internet
standard was always so well bounded, this is not the case.  As counter
examples I propose the following, assuming that a target implementation is
complete and robust:

	- MIME
	- BGP4
	- IKE
	- RFC 822

I claim these all require more effort, based on a mix of personal
experience and observations of how long it takes before we see good
implementations of these protocols deployed.

Steve