[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Software for PKI


At 12:31 PM +0100 11/16/01, Michael Ströder wrote:
Stephen Kent wrote: 

 At 1:09 AM +0100 11/14/01, Michael Ströder wrote:
 >Stephen Kent wrote:
 >>
 >>  This WG is not responsible for broken implementations.
 >
 >I disagree. If a standard is very complicated and features are most
 >times optional it's difficult too implement it correctly and
 >complete. Therefore the designers of a security standard are IMHO
 >indeed somewhat responsible for broken implementations.

 You are right that the more complex a standard becomes, the harder it
 is to implement, and thus the more likely to be broken. But, what
 constitutes a necessary level of complexity, to accommodate a range
 of legitimate "requirements" vs. what is "excessive complexity" is a
 matter of judgement.


Stephen, your answer is very diplomatic and leaves room for every
interpretation. So all of us are right and we all can feel cozy and
warm...

I don't want to offend anybody personally but I feel the need to be
more concrete and a little bit harsh on this:

I'm observing that this working group (and other PKI-related working
groups) most times discusses how to avoid the key word MUST for the
sake of flexibility. Note that every use of key words SHOULD, MAY or
ASN.1 key words OPTIONAL, DEFINED BY, CHOICE etc. causes an extra
need for defining the concrete semantics in a certificate profile
and an extra if-elif-else statement in an implementation. As we
experience today this is very error-prone and unsecure process and
raises costs of PKI deployment dramatically.

IMO simplicity is a crucial prerequisite for security. Therefore a
security standard has to define almost all features/aspects as
mandantory.

Today it has absolutely no meaning that an application is compliant
to PKIX because the room of interpretation of PKIX "standard" is so
wide. It's kind of absurd that this WG - the protocol designers(!)
itself - are reviewing a statement of Microsoft what *they* think
what PKIX compliance of their product means. You should not have to
wonder what "PKIX-compliant" implementation come out of *your*
standard. You have to know it in advance! And a PKIX vendor should
not have to write a statement about his PKIX implementation. It has
to be sufficient that the vendor is PKIX-compliant (tested by a
well-defined test suite checking the mandantory features).

RFC 2459 was published January 1999. Frankly since then I can't see
any added value of PKIX over X.509v1. There's not a single X.509v3
extension defined in PKIX a PKI designer can really rely on. For
each and every extension somebody planning/deploying a PKI has to
check each and every implementation if and how this implementation
interpretes this extension. This is WEIRD!

Now I don't think that the folks working on XML-DSIG and XKMS are
really doing it better. There's also the tendency to be most
flexible by integrating as many PKI standards as possible. Same old
problems...

Ciao, Michael.

Michael,

As for what constitutes PKIX compliance, I agree that there is ambiguity, if one phrases the question in that form. RFC 2459 defines what a compliant CA must support re certificate and CRL generation, and also states what a compliant client must support re processing of basic cert/CRL fields and extensions. But, since there are other PKIX standards, a general phrase such as "PKIX compliant" is ambiguous.

We did fail, as a WG, in having two highly analogous cert request protocols, and we are trying to not fail in that fashion again. Other WGs have also failed in this regard, and we have had similar overlaps in protocol functionality across WG boundaries, which is a failure of the larger IETF (IESG) process. These failures, much like the proliferation of OPTIONAL fields in our standards and in those of most other WGs, have been the price of an open standards process in which we try to accommodate diverse requirements in support of a wide range of business models (of the sort that Todd would like us to devote more time to defining prior to beginning standards development). Standards like PKIX, which are intended to support a wide range of applications, are, of necessity, more general than more narrowly scoped standards. We can either spend tremendous amounts of time debating what are the appropriate uses of these standards, in hopes of narrowing the scope and maybe reducing complexity, or we can accommodate a more diverse set of perceived requirements and create standards that have more optional-to-use-but-mandatory-to-implement features. Since experience suggests there is little reason to have confidence that we can gain consensus on narrower requirements, we have adopted the latter approach.

I'm sorry that you don't perceive any benefits of X.509 v3 vs. v1. I think you are in a very small minority in this regard.

Steve