See also: IRC log
<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
markw: opened a new bug to flesh out algorithm descriptions
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
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
<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
<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
<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
... do you think it's necessary to restrict that?
rsleevi: yes, should require the most compact form
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?
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?
<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: 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
... 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,
... 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
virginie: not really, this is
about web crypto specifically, since h/w was ruled out of scope
... 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
<hhalpin> +1 (happy with a f2f or informal f2f)
show of hands: would you attend a WebCrypto f2f during the week prior to IETF week ?
<terri> -0 (unknown, but seems unlikely)
<hhalpin> Doing it day before STRINT may make sense, keep it one day I think
virginie: 1-day or 2-day f2f?
@hhalpin: i was just going to suggest that
<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?
markw: please look at 24410 and the proposal there
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[End of scribe.perl diagnostic output]