RE: XKMS requirements - initial draft

Hi Sébastien

Thanks for your comments.

Regarding the "X509" elements of KeyInfo, I wonder if interoperability would
be better served if the server MUST support these elements while clients
SHOULD support them. This requirement might also be limited to X-KISS (and
not X-KRSS) so that a server wouldn't be required to issue a certificate but
would have to be able to locate or validate one. I'd be curious to hear what
others thought though.  (After re-reading these requirements, I suspect they
might be more appropriate in the key management spec and not the
requirements document, but still should be discussed.)

You observations re:Private make sense. The element isn't used elsewhere
after all.

Cheers,
Mike 




> -----Original Message-----
> From: spouliot@motus.com [mailto:spouliot@motus.com]
> Sent: Tuesday, November 13, 2001 5:09 PM
> To: www-xkms-ws@w3.org
> Subject: 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
> 
>