Re: Minutes 99-October-28

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Resent-Date:  Thu, 28 Oct 1999 13:41:34 -0400 (EDT)
Resent-Message-Id:  <199910281741.NAA05617@www19.w3.org>
Message-Id:  <3.0.5.32.19991028134130.00bbc6d0@localhost>
Date:  Thu, 28 Oct 1999 13:41:30 -0400
To:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>

>  99-October-28
>  Chairs: Donald Eastlake and Joseph Reagle
>  Note Taker: Joseph Reagle [[4]ascii]
>  
>Participants
>
>     * Donald Eastlake 3rd, IBM
>     * Joseph Reagle, W3C
>     * Mark Bartel, JetForm
>     * David Solo, Citigroup
>     * Ed Simon , Entrust Technologies Inc.
>     * Barbara Fox, Microsoft
>     * Todd Vincent, GSU
>     * John Boyer, UWI (regrets, couldn't get through to bridge)
>       
>  Review of Outstanding Action Items
>  
>Agenda
>
>     * Misc
>       For encoding issues, why not just use Base64 for SignatureValue
>       and DigestValue. Solo: one day, the resulting might be XML CDATA,
>       but till then, the algorithms that we use need to be encoded and
>       Base64 makes sense. Call agrees to define encoding for those two
>       values as Bas64.

Result was elimination of Encoding attribute in DigestValue and
SignatureValue, statement to be added to spec that encoding is base64
for all digest and signature algorithms defined in the spec and up to
the algorithm writing for other digest and signature algorithms.

>       We shouldn't appropriate the control of other institutuional
>       namespaces, we should move back for dsig:foo for the short term
>       until we resolve the issue satisfactorily.
>       
>     * Location - < 10 minutes
>       Leave an attribute but change name to HREF?
>       Make an element with an HREF attribute?
>       Make an element with URI content?
>       Is it mandatory to support a non-null Location?
>
>       List proposal to allow the location to exist outside of
>       SignedInfo. Call wants to keep location in the signature, it is a
>       URI (not necessarily a URL) and the call prefers the employment of
>       redirection/indirection through URIs not this syntax.
>       Leave <ObjectReference Location="http://www.ietf.org"> as is.
>       Define null-location as <ObjectReference Location=""> as referring
>       to this document, must be supported. Do we extend it to mean
>       "#ID". No: Location is URI (including null) or IDREF.
>       (Can anyone remember the reason why we just don't use
>       FragmentIDs?)

That was because Fragment IDs require dispatching on the MIME type as
determined at run time, something a few people thought was valuable
but most thought was unnecessarily complex.  It also tends to lead to
a facility for the Transform pipeline too pass this type along.

>     * Field ordering - < 5 minutes
>       More volatile fields first?
>
>       Placing more volatile fields first might make it harder for
>       bruteforce attacks. Are things like c14n expansion, field ordering
>       really important to the security given our hash algorithms? Do we
>       add a nonce? Call: take to list. (Bartel doesn't want nonce just
>       for static text. Eastlake: some algorithms are weak and might need
>       a nonce, but those are not the best algorithms.) Fox will talk
>       with Jim and crypto guys as to whether we need about how sensitive
>       we need to be about small bits of text, field ordering, and
>       redudancy.
>
>     * Transforms - < 10 minutes
>       Parameters as Parameter elements?
>       Provide for Quoted-Printable decoding?
>
>       No one on the call is opposed to "parameterizing" transform, but
>       Boyer had voiced opposition in the past. (No decision, continue
>       discussion with Boyer present or on list.)
>       Call agrees to list Quoted-Printable as an optional encoding, part
>       of the same MIME reference as the Base64.
>
>     * KeyInfo - <10 minutes
>       Who will do draft of next level of detail?
>       Should recipient identification information not necessary to key
>       agreement be provided for?

Actually, on the second item, the call the previous week wanted the
spec to prohibit such recipient identificaiton information from being
in KeyInfo and say it should be elsewhere if needed.

>       Fox completed her action item; Eastlake acknowledges.
>       Couple of additions, KeyInfo should be defined as ANY and should
>       also have an ID attribute associated with it.
>
>     * "Properties" - < 10 minutes
>       Is properties the best name?
>       Should we define a signing time property?
>
>       Solo: "signature properties" everyone agrees.
>       KeyInfo is also a type of property of an Object. There's
>       discussion as to if you want to have the signature include the
>       KeyInfo, whether you place a KeyInfo in an Object, or just point
>       to the KeyInfo (under Signature) from an ObjectReference.
>       Eastlake: ObjectReference could just point to KeyInfo ID instead
>       of sticking it inside an Object. Call seems favorable but need to
>       think about it more.
>       Put signed-properties as a sub-element of an open content model
>       Object. This allows us to say the stuff in the signed-property
>       bucket can include external XML elements, but that they
>       should/must only carry semantics about the signature generation
>       (like device, or time.)
>       If we define signing time, should be part of a non-normative
>       chapter or seperate document (Reagle would like to have its own
>       namespace for purposes of demonstration.)
>       ...
>       <Object>
>         <SigningTime
>       xmlns="http://www.w3.org/1999/10/signature-core/time">
>             <Date>...</Date>
>             <Time>...</Time>
>             ...
>         </signing-time
>       </Object>

Wouldn't this be

<Object
Type="http://www.w3.org/1999/10/signature-core/signatureproperties">
    <Properties>
        <Property Target="ID of Signature"
                  xmlns="http://www.w3.org/1999/10/signature-core/time">
            <Date>...</Date>
            <Time>...</Time>
            ...
        </Property>
    </Properties>
</Object>

or the like?

>     * Reagle aside: one thing we need to address in our defininitions
>       are things like attribute, property, and such given there are so
>       many collisions.
>       
>     * Schema? - 5 minutes
>       We need someone to try writing a schema, based
>       on the W3C schema draft, of our syntax to
>       see how it goes.
>
>       Ed Simon said he would attempt a Schema.
>       
>     * Canonicalization 
>       Reagle: restate what I though the consensus was
>          + no mandatory to use c14n anywhere.
>          + no mandatory to implement c14n in transforms
>            no mandatory to implement in SignedInfo though hopefully
>            implementation experience can inform further dicission.
>       Solo restatement: SignedInfo: the absense of the c14nMethod then
>       there is no c14n, this is also consistent with Transform. Continue
>       discussion on list.

Actually what happened was that Dave suggested that we needed to
re-introduce the explicit Null canonicalization due to the controversy
over canonicalization of SignedInfo.  I suggested that it wasn't
necessary becasue we could change CanonicalzaitonMethod back to having
a "?" after it and declare its absence to mean null canonicalization.
This makes it more parallel with Transforms.  There was general
agreement with this among those on the call.

>References
>
>   1. http://www.ietf.org/
>   2. http://www.w3.org/
>   3. http://www.w3.org/Signature/Overview.html
>   4. http://www.w3.org/Signature/Minutes/991028-tele,text
>_________________________________________________________
>Joseph Reagle Jr.   
>Policy Analyst           mailto:reagle@w3.org
>XML-Signature Co-Chair   http://w3.org/People/Reagle/

Thanks,
Donald

Received on Friday, 29 October 1999 11:10:18 UTC