Re: Software for PKI

[Michael Ströder <michael@xxxxxxxxxxxx>]

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.