Re: Revised syntax proposal

Richard

KeyInfo and Reference/Object comments in separate notes, otherwise...

Richard D. Brown wrote:
> 
> Dave, Phillip,
> 
> Replies below ...
> > Richard D. Brown Wrote:
> >
> > 8.1- I propose that you adopt a single model for algorithm
> > parameters and attribute values. Either you allow ANY at the top
> > level or you add an intermediary element for type identification.
> >
> > David Solo Responded:
> >
> > I think in all cases I took the <xxx type="typeref"> ANY </xxx>
> > approach.  What is the problem with this?
> >
> 
> Not really. Adoption of a similar model requires the definition of an
> intermediary element for algorithm parameters (counter-part of
> attribute-data).
> 
> <!ELEMENT signedAttributes (attributeData)+>
> <!ELEMENT attributeData ANY>
> <!ATTLIST attributeData
>      type CDATA #REQUIRED
> >
> 
> <!ELEMENT c14nAlg (algParameter)*>
> <!ATTLIST c14nAlg
>     xml:link CDATA #FIXED 'simple'
>     href     CDATA #REQUIRED
> >
> <!ELEMENT algParameter ANY>
> <!ATTLIST algParameter
>     type  CDATA #REQUIRED
> >

This syntax looks fine to me.  If there's no objection (other than
looking for consensus on whether href is the right way to point to
things), we can use it for all the alg types.

> > Richard D. Brown Wrote:
> >
> > 9.1- Why should we specify a c14n algorithm? The content
> > being encapsulated into the sigInfo element, it is implicitly
> > processed during canonicalization of the sigInfo element.
> >
> > I understand that an embedded content may have particular
> > c14n requirements. But, allowing a different c14n algorithm within
> > e sigInfo means that you have to define how you transition from one
> > nonicalizer to the other or the way you expect to pipe the result of
> > one into the other (without breaking the first one).
> >
> > David Solo Responded:
> >
> > I don't like this either, but I still don't see a way around it.
> > Perhaps the c14n crowd and suggest a solution, but I didn't
> > see a way to
> > reconcile the content specific c14n and the general c14n of the
> > signature.
> >
> 
> The point is that the proposed solution might break restrictions imposed by
> the first c14n algorithm. Consider the following:
> 
>   xml-canon( ... | identity(xml-object) | ... )

I agree with the problem, what I don't see is the solution.  Either the
single canon alg for sigInfo has to work for both the sig stuff and
signed object or you need two or you declare that if the same c14n alg
doesn't work, you have to use a reference (which further argues for a
reference scheme in which the object referenced is hashed, but that's
another thread).

> > Richard D. Brown Wrote:
> >
> > 10.1- I suggest that you provide an encoding attribute.
> > Also, we could have share the same definition between content,
> > sigValue, digestValue...
> >
> > David Solo Responded:
> >
> > Why do you think we need flexibility in encoding?  I had hoped that we
> > could define a single encoding for all our top level items.
> >
> 
> Agreed that we can limit encoding to base64. But we still have to
> distinguish between encoded and non-encoded content.

Where do you think this is an issue (if it refers to the signed object,
then I think the encoding info belongs in the definition of the
encapsulated type, not in signature)?

> > Richard D. Brown Wrote:
> >
> > 14.1- May not have to be defined by this specification.
> > Whoever needs something like that could reuse the resource
> > element definition.
> >
> > David Solo Responded:
> >
> > I expect that this should move into a "useful types" section in the
> > larger document along with bag-o-certs and other things.
> >
> 
> I am not sure that Manifest remains a useful type. Let consider an embedded
> list of resources in the signature. I can do so without a Manifest:
> 
> <sigInfo>
>   <resource>
>     <value encoding='none'>
>       <resource>
>         <location .../>
>       </resource>
>       <resource>
>         <location .../>
>       </resource>
>     </value>
>   </resource>
>   ...
> </sigInfo>

It doesn't particularly matter to me whether we define this or not -
anyone else have thoughts?

> Sincerely,
> 
> Richard D. Brown

Dave

Received on Monday, 16 August 1999 10:41:37 UTC