RE: [widgets] Minutes from 7 August 2008 Voice Conference

Hi Art, All,

Unfortunately I won't be able to attend today's call but would like to
provide feedback on some of the discussions from last week's call. 

On the addition to R11, specifically:

"A conforming specification SHALL specify that if none of the signatures
and certificate chains can be verified, e.g. because of missing root
certificates or where any certificates in the chain have expired or are
not yet valid, then the widget resource SHALL be treated as unsigned. A
conforming specification SHALL specify that the widget environment SHALL
not install or load a widget resource when it can determine that any
certificate in the chain has been revoked."

There was a desire to clarify what was and wasn't allowed and to check
that this didn't lead to any inconsistent behaviour.
 
To re-cap this addition was a result of a desire to treat widgets that
are known to be bad (e.g. that have been revoked) differently from
widgets for which the widget platform cannot verify the signature
because of missing or out of date information. In the former case we're
suggesting that the correct action would be to not install the widget,
in the latter the widget should be treated as if it hasn't been signed.
The issue was identified on the call that in some cases revoked
certificates are removed from CRLs once they have expired. In this case
the above rules could lead to revoked widgets being treated as unsigned
widgets, which would not be satisfactory. To address this case we
suggest the addition of the following sentence:
 
"CRLs for certificates used in certificate chains associated to signed
widgets SHALL include expired certificates"

I think a similar proposal was made by Thomas on the call and to us it
is the best way to resolve the issue.

On the comments to R38 there was a desire to re-word our proposal on the
ability to add new root certificates. The proposal was:
 
"A conforming specification SHOULD define mechanisms to enable end-users
to install additional root certificates, provided this is compatible
with the security policy of the widget processing environment."
 
The suggested re-wording would look something like:
 
"Implementations MAY provide mechanisms to enable end-users to install
additional root certificates. Trust in a root certificate is established
through a security critical mechanism implemented by the widget platform
that is out of scope for this specification."
 
There was also a discussion on the new requirement titled "Signing
procedure agnostic". The request was to re-formulate this requirement so
that it was specific to the widget specifications. However, having
looked in detail at the PKCS#11 specification we are inclined to suggest
that the requirement is possibly out of scope. The PKCS#11 specification
details how applications can use the interface and what this means in
terms of their processing logic but it should be possible to meet the
requirements it makes with whatever scheme is defined in W3C. We still
believe that PCKS#11 support will be vital for widespread adoption of
the specification but perhaps on closer inspection this specification is
not the right place to make this a requirement. 

We of course welcome any feedback on the above.

I look forward to meeting you all in Turin,

Mark
  

-----Original Message-----
From: public-webapps-request@w3.org
[mailto:public-webapps-request@w3.org] On Behalf Of Arthur Barstow
Sent: 07 August 2008 13:25
To: public-webapps
Subject: [widgets] Minutes from 7 August 2008 Voice Conference


The minutes from the August 7 Widgets voice conference are available at
the following and copied below:

  <http://www.w3.org/2008/08/07-wam-minutes.html>

WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before August 14 (next voice
conference); otherwise these minutes will be considered approved.

-Regards, Art Barstow

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                        Widgets Voice Conference

07 Aug 2008

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0318.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/08/07-wam-irc

Attendees

    Present
           Art, Nick, David, Luca, Claudio, Mark, Marcos, Thomas, Arve,
           Bryan

    Regrets
    Chair
           Art

    Scribe
           Art

Contents

      * [4]Topics
          1. [5]Agenda Review
          2. [6]Annoucements
          3. [7]R11 Digital Signatures
          4. [8]R38 Addtional Digital Certs
          5. [9]Proposed Requirements
          6. [10]Signing Procedure Agnostic
          7. [11]AOB
      * [12]Summary of Action Items
      _________________________________________________________


    Date: 7 August 2008

    <scribe> Scribe: Art

    <tlr> whooops

    <scribe> ScribeNick: ArtB

    <tlr> zaim, I am thomas

    <marcos> I would never!

    <marcos> :)

    <marcos> oh crap. I'll dial in again.

    <marcos> tlr, was it me?

    <marcos> hmmm...., there is nothing next to me or any other device.
    Will dial in again

Agenda Review

    AB: Agenda:
    [13]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
    18.html

      [13] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0318.html

    <marcos> any better?

    <marcos> bah!

    <arve> doesn't zakim have some function to see who's making noise?

    <tlr> gah

    <tlr> zkaim, ??P8 is marcos

    AB: any change requests for the agenda

    <marcos> hmmm... sorry about this.

    AB: [none]

Annoucements

    AB: registration for the Turin f2f is open; please register ASAP
    ...
    [14]http://www.w3.org/2006/appformats/group/TurinF2F/Participants

      [14] http://www.w3.org/2006/appformats/group/TurinF2F/Participants

    Claudio: must bring a Passport or valid ID
    ... company badge is probably not going to work

    <tlr> I hope there is no NDA coming along with the ID requirement.

    <scribe> ACTION: Barstow passport is required for Turin f2f meeting
    [recorded in
    [15]http://www.w3.org/2008/08/07-wam-minutes.html#action01]

    <trackbot> Created ACTION-21 - Passport is required for Turin f2f
    meeting [on Arthur Barstow - due 2008-08-14].

R11 Digital Signatures

    AB: OMTP input
    [16]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
    08.html
    ... request mods to several signature reqs and propose some new reqs
    ... who is going to lead the OMTP discussion?

      [16] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0308.html

    David: Mark will lead the tech discussion

    AB: the proposal expands on the existing text in R11

    Mark: we think the req needs some clarifications
    ... we also propose additional behavior e.g. when there are
    signature chains
    ... need to say what the client will do in various scenarios
    ... need consistent behavior
    ... need to say what happens if the chain can't be verified
    ... e.g. if missing root cert
    ... e.g. if cert is expired
    ... we suggest the Widget should be considered unsigned

    Arve: I'm concerened about treating the resource as valid
    ... it could encourage unsafe behavior by the user
    ... Some users aren't qualified to "make the right decision"

    <marcos> MC: I share Arve's concerns.

    Arve: e.g. is it safe to treat the package as safe

    <marcos> MC: and by unsigned, what do you mean?

    Mark: if the widget is not signed, it should never be presented as
    if it is signed

    Arve: need to clarify unsigned versus invalid
    ... an invalid widget should not be launchable

    Mark: if the root cert is missing we want the widget to still be
    launchable but just not as a "signed" widget

    <marcos> MC: hmmmm.... this results in "security profiles"

    Mark: we don't want additional security privs for an unsigned widget

    TR: want to consider the proposed addition in one piece
    ... If none of the parts can be verifed, treat as unsigned
    ... have a couple of concerns
    ... should install continue if there some part cannot be verified or
    fails verification
    ... Need to address revoked/unrevoked versus expired
    ... We need a consistent model here
    ... and a simple model
    ... but very clear on these issues
    ... Don't want to have an unexpected consequences

    Mark: we are certainly open to reformulating this text
    ... Perhaps we need to flesh out the details of this req
    ... We have some error cases that must be addressed
    ... I will investigate CRL lists
    ... Think we should continue discussions over e-mail

    TR: I understand your concerns Marks
    ... but we need some additional text re the CRL handling
    ... There are also some deployment concerns re revocation
    ... we need to think about those issues too
    ... is there a different UC re revocation then the "normal" ones?

    AB: Mark, what are the next steps for this req?

    Mark: encourage people to discuss on the public mail list
    ... I will take the lead on reformatting the text

    AB: Mark, Thomas - is there some Use Case work that needs to be
    done?

    <tlr> That background explanation would be useful, indeed.

    Mark: I can elaborate on the justification

    TR: yes, I think some background info would be useful

    <marcos> MC: yes, they seem mostly ok

    Mark: are people OK with the proposed rationale in our input?

R38 Addtional Digital Certs

    AB: R38:
    [17]http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/#r38.-

      [17] http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/#r38.-

    Mark: there is some interaction here with the security policy and
    root certs
    ... need a mechanism to define the relationship

    Marcos: I think the proposal is good

    Arve: if the engine has a mechanism for installing or uninstalling a
    root cert, then I think a MAY is sufficient

    Mark: need to be more explicit about the relationship between the
    root cert and security policy
    ... in BONDI expect a hook between a root cert and a security policy
    ... root certs will have different trust levels

    <arve> Do we need to define a method to define/export trust
    level/security configuration for certificates? What would this need
    to look like?

    Mark: we haven't made a final decision on the various approaches we
    have talked about
    ... would like to get some feedback on this issue
    ... This is a broader issue then just widget signatures

    TR: we are moving into much larger secuity models
    ... I don't think those type of broad policy models should be in
    scope for the signature spec
    ... Say "can install root certs; there may or not be restrictions on
    how they are used" but perhaps not a lot more

    Arve: I tend to agree
    ... the issue is more about trust delegation

    TR: it's also about how you shape the market
    ... suggest a relatively dry model
    ... and not try to address broad policy issues

    Mark: I also tend to agree with Thomas
    ... The topic does need to be addressed i.e. security policy and we
    will continue to work on it in BONDI

    AB: so where do we stand on this req?

    Mark: think we need to refine the wording
    ... And also address Thomas' concerns

    <tlr> Trust in a root certificate is established through a security
    critical mechanism that is out of scope for this specification.

    Mark: this discussion is also relevant to R43

    TR: a problem with policies here is that the industry is doing
    different things here
    ... we need to be careful not to go in YA direction

    Mark: we need to define some behavior

    Marcos: yes, the engines are doing different things
    ... Arve already posted their model

Proposed Requirements

    AB: how do we want to address these?

    Marcos: I think they are mostly good
    ... and I can add them as is

    Mark: Thomas submitted some reqs
    ... Signing Procedure Agnostic is one TR responded to and I'd like
    to take it first

    Bryan: the MWBP WG also propsed some new reqs
    ... have they been received?

    Marcos: yes, I saw them

    <tlr> marcos, URI?

    Marcos: I haven't had time yet to read them in detail
    ... I will respond soon-ish

Signing Procedure Agnostic

    <marcos> tlr... getting it.

    <marcos> tlr :
    [18]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/02
    98.html

      [18] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0298.html

    <marcos> and
    [19]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/at
    t-0298/MWBP_comments_to_Widget_Requirements_Last_Call_WD.htm

      [19] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/att-0298/
MWBP_comments_to_Widget_Requirements_Last_Call_WD.htm

    Mark: I think this req needs some clarification
    ... we expect scenarios with different Actors involved

    <marcos> MC: Here is link to Arve's security input:
    [20]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
    32.html

      [20] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0332.html

    AB: Thoma's comments on this:
    [21]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
    25.html

      [21] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0325.html

    Mark: we need to decide what is mandatory to support
    ... Re PKCS#11 interface, it is being used today
    ... thus we see a need for some interop

    TR: so the req is "don't mess up the ability for smart card to be
    used"
    ... on the face, it make sense
    ... But what does this req actually apply to?
    ... e.g. does it apply to every crypto mech that could be plugged in
    ... Need some examples; what are the challenges.

    Mark: those are good points

    <tlr> Put differently, this may be a slam-dunk or a major problem. I
    suspect slam-dunk, but I'd like to be sure of that.

    <scribe> ACTION: Mark create some motiviation and examples for the
    proposed Signing Procedure Agnostic requirement [recorded in
    [22]http://www.w3.org/2008/08/07-wam-minutes.html#action02]

    <trackbot> Created ACTION-22 - Create some motiviation and examples
    for the proposed Signing Procedure Agnostic requirement [on Mark
    Priestley - due 2008-08-14].

    Marcos: not clear what the WG will do with this input

    Mark: I think we may need to break it down a bit
    ... we need to make sure we don't break existing mechanisms

    Marcos: should we establish a more formal liaison with XML Security?

    AB: I think that make sense
    ... after we have fine-tuned the signature reqs

    TR: I can help liaise with the XML Security WG
    ... when we understand the PKCS#11 req better, we should discuss it
    with XML Sec

    <claudio> +q

    Mark: perhaps some of our proposed reqs are more appropriate for the
    XML Sec WG to address

    Claudio: in general we'd like OMTP to provide some clearer Use Cases
    ... we think it would facilitate the discussion

    <tlr> +1 to Claudio, actually

    Claudio: would also help us understand whether or not the reqs are
    out of scope or in scope

    Mark: we have provided rational for some of the reqs
    ... It would be better if people were mor explicit about which reqs
    need more information

    Claudio: the rationale is good but security models and policy are
    quite broad and knowing specific Use Cases would be very helpful
    ... again to help with "scope" related issues
    ... having the Use Cases more explicit now should actually make the
    spec work go quicker

AOB

    TR: when is the next conf call?

    AB: next week; same time
    ... End of Meeting

    <claudio> quit

    <Luca> quit

Summary of Action Items

    [NEW] ACTION: Barstow passport is required for Turin f2f meeting
    [recorded in
    [23]http://www.w3.org/2008/08/07-wam-minutes.html#action01]
    [NEW] ACTION: Mark create some motiviation and examples for the
    proposed Signing Procedure Agnostic requirement [recorded in
    [24]http://www.w3.org/2008/08/07-wam-minutes.html#action02]

    [End of minutes]

Received on Wednesday, 13 August 2008 12:19:51 UTC