See also: IRC log
Date: 7 August 2008
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
<tlr> zaim, I am thomas
<marcos> I would never!
<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
<marcos> any better?
<arve> doesn't zakim have some function to see who's making noise?
<tlr> zkaim, ??P8 is marcos
AB: any change requests for the agenda
<marcos> hmmm... sorry about this.
AB: registration for the Turin
f2f is open; please register ASAP
Claudio: must bring a Passport or
... 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 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].
AB: OMTP input
... request mods to several signature reqs and propose some new reqs
... who is going to lead the OMTP discussion?
David: Mark will lead the tech discussion
AB: the proposal expands on the existing text in R11
Mark: we think the req needs some
... 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
... 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
... 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?
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
... 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
... suggest a relatively dry model
... and not try to address broad policy issues
Mark: I also tend to agree with
... 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
... 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
AB: how do we want to address these?
Marcos: I think they are mostly
... and I can add them as is
Mark: Thomas submitted some
... 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
<marcos> tlr... getting it.
Mark: I think this req needs some
... we expect scenarios with different Actors involved
<marcos> MC: Here is link to Arve's security input: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0332.html
AB: Thoma's comments on this: 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 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
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
TR: when is the next conf call?
AB: next week; same time
... End of Meeting
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/assinged/unsigned/ Succeeded: s/unvalid/invalid/ Found Scribe: Art Found ScribeNick: ArtB Present: Art Nick David Luca Claudio Mark Marcos Thomas Arve Bryan Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0318.html Found Date: 07 Aug 2008 Guessing minutes URL: http://www.w3.org/2008/08/07-wam-minutes.html People with action items: barstow mark[End of scribe.perl diagnostic output]