2009/2/12 Priestley, Mark, VF-Group <mark.priest...@vodafone.com>: > > Thomas Roessler wrote: > >>> Just for clarity, there are two possible requirements around OCSP and >>> CRLs: >>> >>> - support embedding an OCSP response (or a CRL, or a link to a CRL) >>> in the mark-up of signatures >>> - support querying OCSP responders (and CRLs) as part of >>certificate >>> validation >>> >>> I'd argue that the latter is more important than the former. > > [mp] I agree latter is more important, but see below... > > Frederick Hirsch wrote: > >>we need explicit schema support (in Signature 1.1) for >>explicit OCSP responses, for the latter a processing rule in >>widgets signature may be enough. Perhaps this does not need to >>be required must in the widgets spec, depends on requirements. >> >>Mark, I believe you mentioned you have additional thoughts on >>these requirements. > > [mp] The requirements state that it must be possible to include > revocation information in the signature, and when present that the > specification should say how to process this information [3]. On > re-reading this requirement, I wonder whether we didn't fold two > requirements into one and not get it quite right... In any case, looking > at the requirement afresh, as Thomas and Frederick suggest, the ability > to include OCSP responses in signatures should be addressed in XML > Signature Syntax and Processing Version 1.1 [4]. Our requirement should > probably be changed to be the ability to process revocation information > contained in the signature, and should probably be a SHOULD.
Ok, that makes sense. > In regards to the processing of revocation information, orignally I was > pushing for Widgets 1.0: Digital Signatures [1] to include an OCSP and > CRL profile to try and help ensure interoperability between OCSP/CRL > clients and responders/servers across organisations. My suggestion for > an OCSP profile would have been to reference (or take inspiration from) > the OMA Online Certificate Status Protocol Mobile Profile [2], however, > I'm no longer sure that this is a good idea. This profile is obviously > aimed at mobile devices and therefore may create inter-operability > issues for non-mobile implementations (and mobile implementations that > don't follow OMA). > > So more generally, I would propose that OCSP and CRL processing should > be removed from [1]. The reasoning being that it is likely that other > standards bodies, companies and organisations will want to specify this > behaviour in order to work with their existing infrastructure. I am more > and more of the opinion that [1] should simply provide the format and > processing rules that enables the use of interoperable signatures across > widget user agents. How these signatures are used should be covered > elsewhere. Ok, that would make things a bit easier. -- Marcos Caceres http://datadriven.com.au
