Re: [widgets] Getting synch'ed up on Widgets Digital Signatures

2009/2/12 Priestley, Mark, VF-Group <Mark.Priestley@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

Received on Friday, 13 February 2009 13:30:06 UTC