RE: Revised syntax proposal

Richard:

Your comment:

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

Mine: 

I have three problems with this:

(1) KeyInfo in PKIX means the algorithm and the key. What you're talking
about is along the lines of SignerInfo in CMS (where the set, of course may
be 0). If it has to survive, then at let's change the name. 

(2) For many signed XML applications, there are going to be only
pre-negotiated keys, so this KeyInfo can't be mandatory.  

(3) My strongest objection though is that your KeyInfo attaches semantics to
the signature (or presumes that a cert does) which is outside the scope of
this wg.

--Barbara Fox
Security Architect, Microsoft


-----Original Message-----
From: Richard D. Brown [mailto:rdbrown@globeset.com]
Sent: Friday, August 13, 1999 9:23 AM
To: 'David Solo'; 'Phillip M Hallam-Baker'
Cc: w3c-ietf-xmldsig@w3.org
Subject: 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 14:11:13 UTC