RE: Revised syntax proposal

Dave, Phillip,

Replies below ...

> Richard D. Brown Wrote:
>
> 1.2- I still argue that there is no obvious benefit to keep
> the KeyInfo element outside the scope of the signature. Conversely,
> there are known attacks on the signature when the KeyInfo is not
protected.
> Among others, if a party is issued a plurality of certificates for a same
> key but different attributes, you can substitute one certificate for
another
> without impairing signature verification. Probably some will argue that it
is
> a flaw in X509 (actually true for a large majority of the
certificate-based
> infrastructures in place) and that the key alone should prevail.
> Unfortunately, the world is the way it is, and for the forseeable future I
feel
> that we should accomodate with it and its flaws.
>
> David Solo Responded:
>
> While I think we could do it either way, my preference is to have it
> outside the sigInfo.  If an application wants to bind the certificate
> (or other keyInfo) selected under the signature, then it can add a
> signedAttribute (ala CMS); however if you move the keyInfo
> into sigInfo, and an application doesn't want the binding, there
> isn't an option. Moving it into sigInfo implies to me an expectation that
> base validation rules would do something with it, and I think we've ruled
> that out.
>
> Phillip M. Hallam-Baker Responded:
>
> It is always the recipient which has to decide whether the trust
> chain has the desired quality. Ultimately it is access to the private
> key which is the only property which provides for identity binding.

> I hope that nobody would suggest that the sender attempt to
> enforce the choice of trust chain for verification on the recipient.
> The same message may be sent to multiple recipients which would need
> to verify the message according to different trust axioms. Cross
> [, extreemly cross and downright incandescent with rage] certificicates
> may well be involved at this point.

KeyInfo should not be mistaken with the actual credential or key being used.
KeyInfo only consists of a unique and unambiguous reference to the key or
the credential that is used, as well as optional details regarding
establishment of a one-time session key.

I strongly feel that if one is signing wrt a given credential, the reference
to that credential shall be sealed in the signature - not the credential nor
the chain. If not, I can't imagine how we could satisfy with current
certification practices. Unless you implicitly rule out the use of attribute
certificate (by opposite to identity certificate that you have referred
to)...

> Richard D. Brown Wrote:
>
> 2.2- I would not distinguish between obejct and reference
> at this level. From a model standpoint, the signature is applied to a
> resource, which one can be given by reference or by value. The
> distinction should be done further down the tree.
>
> David Solo Responded:
>
> I think this is the biggest issue we need to debate.  If validation
> always stops with the encapsulated item then I agree we only need one
> type here.  The challenge is how to handle the usage
> scenarios where the
> signature element is added to the thing its signing:
>
> <package>
>   <signedthing/>
>   <signature/>  (with ref, including digest, to signed thing)
> </package>
>
> The goal of the reference type (and the processing rule you comment on
> in point 17) is to try to accomodate the expectation that the default
> behavior of a detached sigature (or non-encapsulating signature) will
> actually check the digest over the thing begin pointed to
> (i.e. validate
> the integrity and authenticity of the signed thing, not just
> the ref).
> While I continue to agree with the assertion in Boston and
> Oslo that we
> don't recurse for links/resources in manifests and other documents; I
> think we need to address this particular case.
>

I strongly feel that it is an application-level issue. Nonetheless, if we
were to address this problem in the current specification, I would rather
use some 'attribute' on the resource element to do so. It is not because I
am making use of a reference (by opposite to embedded) that I necessarily
want the resource to be verified. Therefore, the distinction should be more
specific.

> 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
>


> 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) | ... )


> 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.


> 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>

Sincerely,

Richard D. Brown

Received on Friday, 13 August 1999 12:23:45 UTC