Re: XKMS requirements - initial draft

Hello list,

After a quick review I see two problems in the current requirements draft.
Both come from section 3.3.4.

The following KeyInfo formats MUST be supported: KeyName, KeyValue,
X509Cert, X509Chain. The following KeyInfo formats MAY be supported:
X509CRL, OCSP,RetrievalMethdod,MgmtData, PGP, PGPWeb, SPKI, Multiple...(in
addition to the XKMS registration Private format which MUST be supported)


a.   Why are X509Cert and X509Chain a MUST ?

Although this may not be the case, at least initially, I'm convinced that
many applications will use XKMS services without the need of X509
certificates. In this case a perfectly working XKMS service would be
considered "non-compliant" because it doesn't generate X509 certificates
(for which it has no use).

Also, the requirement to support these certificates puts an additional
burden on the software developers and may only result in more "broken" X509
certificates in the wild (i.e. please generate, possibly broken, X509
certificate in order to be XKMS "compliant"). I can tell (from experience)
that an XKMS service, conforming to today specs, offering X509 certificates
has more than 50% of its source code in the X509 certificate generation.
Well this may not be a problem if you need them but do we? Probably.
Always? Nope.

Or shouldn't the support for X509 certificates be optional (like other
types of certificates)?
Or maybe it should get some kind of "special" treatment as a major
interoperability issue?


b.   Support for Private

This support is only required for:
     i.   key(pair)s generated by the service and returned to the user;
     ii.  service supporting key recovery;

As I can easily imagine an XKMS service which doesn't provide these
features (like mine ;-) supports for Private seems optional (at least if we
consider these features optional - or are we deciding _now_ that they are
required?).


So, in concordance with RFC2119, couldn't the requirement (in section
3.3.4) be changed to something like:

The following KeyInfo formats MUST be supported: KeyName and KeyValue.
The following KeyInfo formats SHALL be supported if the service supports
interoperability with X509: X509Cert and X509Chain.
The following KeyInfo formats MAY be supported: X509CRL,
OCSP,RetrievalMethdod,MgmtData, PGP, PGPWeb, SPKI, Multiple...
In addition to the XKMS registration Private format which SHALL be
supported if the service support either service generated key pairs or key
recovery.

--------------------------------------------------------------
Sébastien Pouliot
Architecte Sécurité / Security Architect
Motus Technologies
tel: 418 521 2100 ext 307
courriel / email: spouliot@motus.com

Received on Tuesday, 13 November 2001 17:09:10 UTC