<wseltzer> trackbot, prepare teleconf

<trackbot> Date: 27 January 2014

<virginie> hi all, please join the call on the usual number but use the code 26632 (CONF2)

how do you do the scribe nick thing?

markw: suggest discussing a f2f in March

<hhalpin> Scribenick: rbarnes

virginie: good point

<hhalpin> Note that I've sent the request to co-ordinate Bugzilla to mailing list to our Systems Team

<hhalpin> we should have an answer shortly

markw: went through the 15 bugs that virginie had identified
... several have been discussed and can be closed; proposed resolutions ahead of this meeting
... proposed fixes are in the ED of 24 jan

<virginie> https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%20cryptography

markw: opened a new bug to flesh out algorithm descriptions

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html

virginie: what would be helpful here? do you think that you authors will be able to finish everything soon?

markw: would be helpful to visit issues marked as OPEN
... the resolutions for most are minimal; the new bug is more substantial

<virginie> reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=20611

<virginie> Reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=22570

rbarnes: how is tag put in according to the current spec? need to have something

<jimsch> +0

rsleevi: pkcs11-style, appended to the ciphertext

<rsleevi> current construct for AEAD is Input = (Ciphertext)+(Tag), output = (Ciphertext)+(Tag)

<hhalpin> sounds good to me, don't see how that can go wrong

<jimsch> +q

<virginie> 23831reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23831

<hhalpin> Back to broken crypto, but SHA-1 is used a lot

jimsch: should acknowledge that SHA1 is used sufficiently widely

<rsleevi> +1

<hhalpin> I'm happy to add it along with some kind of warning

<rsleevi> hhalpin: There's no need for "warning"

<terri> +1 to adding a warning

markw: any other opinions?

hhalpin: as long as there's some warning text

rsleevi: not necessary, e.g., HMAC-MD5 is not affected
... weaknesses of SHA1 do not affect HMAC-SHA1

<virginie> note that the bug to be reviewed can also be seen under http://lists.w3.org/Archives/Public/public-webcrypto/2014Jan/0039.html

<hhalpin> Thought it was SHA1 in general

markw: will add SHA1 to recommended algorithms, with no warning

<rsleevi> @hhalpin: See rfc6151 Sect 2.3 for the discussion of HMAC-MD5 construction

<terri> perhaps a note that it is not affected would be helpful, but I guess not necessary

reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23445

<virginie> reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23445

markw: propose just adding an implementor note re: conversion to form with a sign bit

rsleevi: agree with adding the clarification, but think it should be normative

<hhalpin> +1 normative if it's a place for possible divergence

markw: the fact that it's an unsigned integer is normative, so it's not ambiguous in the spec

rsleevi: speaking from an implementor side, there is ambiguity

markw: just to be clear, there can be an arbitrary number of leading zeros with the current spec
... do you think it's necessary to restrict that?

rsleevi: yes, should require the most compact form

<jimsch> q_

rbarnes: seems sensible to put the requirement on BigIntegers produced by the API, while requiring the API to be tolerant of leading zeros

jimsch: cautious of requiring things to be minimum-length, since it's sometimes easier to have fixed-length buffers

markw: do you mean within UA or JS?

jimsch: JS

markw: so requiring API to be tolerant would address that

<virginie> reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23500

markw: everyone OK with requiring API to produce most compact, but tolerate leading zeros?

rbarnes: yep

<hhalpin> The raw AES came from Boneh

markw: discuss this now, or continue on the list?

<virginie> reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23729

markw: seems like there's agreement to use DOMStrings, will work on implementing that

<rsleevi> BUG 23503?

<virginie> reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23503

markw: had some discussions, seems like there's not an immediate need for extensibility

rsleevi: the only change we'll be making to named curves is going from enum to DOMString
... makes it easier to add new named curves

markw: are there any other enums lurking around?

rsleevi: key type (pub/priv/secret) and key format (pkcs8/jwk/...)
... maybe should just change all to DOMString
... impact is just that we have to say how unknown DOMStrings are handled

markw: will create a new bug for enum->DOMString conversion in general

MichaelH: for things like padding, how do you change the DOMString?

rsleevi: the change from enum to DOMString does not change the process for extending the API. they're all spec updates

MichaelH: does adding a new algorithm require updating the spec?

rsleevi: yes, it always has

<virginie> reviewing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23495

<hhalpin> Note that we can't update the spec per se after going to Last Call, but I imagine we'll start a 1.1 WD and continue the WG

<hhalpin> so having the group add a new algorithm is possible as long as WG is running

<rsleevi> @Richard: Requiring spec updates has worked just fine for every other deployed WebAPI :)

@rsleevi: other specs don't have as many variants and nation-defined parameters. don't want to have those fights

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24410

virginie: any objection to implementing these plans, then going to LC

<hhalpin> I'd like a time estimate from the editors

<rsleevi> @rbarnes: Luckily, few UAs care about those variants and nation-defined parameters. That said, three compat implementations = ship it = fine by me

<hhalpin> if they have any idea

jimsch: when we say "LC", do we mean LC within this group? how long does it last?

<rsleevi> Last Call -> Call for Implementations

hhalpin: LC is the LC for public comment, usually give that 6 months, hopefully with implementation continuing
... any comments we have to address or explain why they're out of scope
... we usually advertise a lot during that period

<hhalpin> Last Call -> PR -> CR -> Rec

rsleevi: harry skipped a step in the process; call for implementations follows LC
... spec may change based on implementation experience

<hhalpin> Actually I mentioned that Ryan :)

<hhalpin> However, after Last Call we don't have to take comments from the entire Internet and can focus on test-suites/implementation

<hhalpin> How about 1 month?

rsleevi: would like to give the WG a chance to review before LC
... skeptical about that getting done in even 1 week

virginie: can we expect a new version on 10 Feb?

<hhalpin> How about end of February?

<hhalpin> For actual transition

markw: to address today's bugs by end of Feb would not be a problem; 24410 might be doable
... agree that we need to give WG members more than a few days to review

virginie: so how about a 6 week timeline, with 4 weeks edit, 2 weeks WG review?

markw: ok with me

<hhalpin> Hitting Last Call at IETF would help review

<jimsch> Do we need to address tag feedback?

<hhalpin> since we could then discuss with everyone at IETF

<hhalpin> TAG feedback can be addressed in Last Call period

virginie: we can re-evaluate the WG review timeline once the new version is out

hhalpin: hitting LC right before/after the IETF could be helpful, since we could advertise there

<hhalpin> Note as regards CR/PR distinction, yep its WD->Last Call->CR->PR->Rec

<rsleevi> @hhalpin: I don't see a lot of value either way

<hhalpin> CR is for implementers and PR is for AC review

rsleevi: other specs typically do one push per bug

@hhalpin: i agree with rsleevi, not much different

markw: will certainly be one commit per bug, question is whether to push them all at once

rsleevi: tend to batch push, say at the end of the day

<hhalpin> Well, if we wait around till say March or April to hit Last Call, we are slipping and it seems like we want to get most of our review in before summer break 2014 hits

virginie: this is a different, long-term topic
... in december, there was an idea to have a workshop on integrating hardware into webcrypto
... some folks have said that h/w tokens might be too limited
... maybe discuss "trusted things" generally (h/w or s/w)
... what feedback to people have?

terri: is this related to discussion of h/w tokens on sysapps

<anders> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Dec/0004.html

virginie: not really, this is about web crypto specifically, since h/w was ruled out of scope earlier
... sys apps work is more raw access

<hhalpin> We'll keep tabs and co-ordinate, depending on how implementaiton goes

hhalpin: we will coordinate with sys apps, and other parts of the w3c
... important not to have the workshop too early, since we want to have the main spec more or less out of the woods
... that would probably put it in the latter half of 2014
... workshop would not change the charter of the WG or the initial spec, more about long-term vision
... having that discussion early could help smooth things out in the WG

<hhalpin> i.e. start discussion early, but implement one thing at a time :)

rbarnes: would be useful to have a workshop and see if we can do something here
... US DHS is very interested in using their existing PIV credentials with web apps
... BBN might have some experiments to talk about soon

virginie: not hearing anyone calling for the more general "trusted thing" scope. will come back for more details
... now, should we have a f2f in march?

<hhalpin> Who is at IETF?

@hhalpin: i will be at ietf

<jimsch> Not I

scribe: focus of f2f would probably be future work

<markw> I would come to an F2F

scribe: maybe if people are going to be at IETF, we could have at least, say a half day

<hhalpin> We could do any last minute Last Call bug discussion and then think about Workshop scoping

<jimsch> -1

<hhalpin> +1 (happy with a f2f or informal f2f)

<virginie> +1

show of hands: would you attend a WebCrypto f2f during the week prior to IETF week ?

<markw> +1

+1

<terri> -0 (unknown, but seems unlikely)

<rsleevi> -0

<hhalpin> Doing it day before STRINT may make sense, keep it one day I think

virginie: 1-day or 2-day f2f?

<rsleevi> 1

@hhalpin: i was just going to suggest that

<virginie> 1

1

<hhalpin> https://www.w3.org/2014/strint/

<hhalpin> That puts us on Feb 27th

virginie: will see if i can organize this during that week, see if we can have a location

hhalpin: w3c has decided that during the korean WWW conference, they will be doing a web crypto session in the developer track

<hhalpin> As regards Korea, we'll be doing a developer session in Korea in April on WebCrypto

virginie: so we will try to make something happen on the 27th of february
... any other business?

<rsleevi> 24410

markw: please look at 24410 and the proposal there

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24410

markw: it's going to be a lot of work, don't want to start unless we agree

rsleevi: a little nervous with what's been proposed; don't know if it will be sufficient to do what you've proposed

<hhalpin> +1 rbarnes

rbarnes: maybe do one of these things so we know what you're really talking about

<hhalpin> to repeat rbarnes, "Can you give one iteration before we begin going through all of these?"

rsleevi: have attempted to fully specify one or two, maybe compare/contrast

virginie: next call in two weeks

<hhalpin> trackbot, end meeting

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/a few days/more than a few days/
Found ScribeNick: rbarnes
Inferring Scribes: rbarnes

WARNING: No "Topic:" lines found.

Default Present: Virginie_Galindo, terri, markw, jimsch, rbarnes, Karen, hhalpin, +1.650.275.aaaa, rsleevi
Present: Virginie_Galindo terri markw jimsch rbarnes Karen hhalpin +1.650.275.aaaa rsleevi

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 27 Jan 2014
Guessing minutes URL: http://www.w3.org/2014/01/27-crypto-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report