See also: IRC log
<trackbot> Date: 12 October 2015
<scribe> scribe: hhalpin
bal: The reason I dove onto this
call to discuss CFRG's supposed output
... given recent Suite B announcements
... I've gotten lots of questions
virginie: We'd like Microsoft's
input on implementing various algorithms
... in particular, RSA-PSS
Note last time Vijay said it wasn't likely for RSA-PSS to be implemented in WebCrypto soon
Note also I believe Israel has left Microsoft I heard?
So maybe ask Vijay?
bal: this will be my personal opinion, not a product commitment
<virginie> to hhalpin : yes, for israel leaving , heard too :)
I'd like to have a procedure for adding algorithms at the end of this meeting.
bal: We have less
interoperability than we hoped for across a wide variety of
algorithms
... for example, we're not seeing RSA-PSS implemented
... would polyfill count? We've shipped that.
<virginie> ACTION: hhalpin to clarify polyfill versus native in the implementation count [recorded in http://www.w3.org/2015/10/12-crypto-minutes.html#action01]
<trackbot> Created ACTION-153 - : clarify polyfill versus native in the implementation count [on Harry Halpin - due 2015-10-19].
I'm OK with a polyfill, but I'd have to check with W3C
bal: Again, new investiment is in
Edge, so unclear how it will come.
... we aren't talking about a browser profile
... we're talking about two communicating points
... two Javascript implementations should count
... Note we've moved on, I don't have a lot of cycles
... if there's code out there, we can do that
... if we want it all to be native in the browser, that's
fine
virginie: What are the chances that if something in polyfill becomes native in browser?
bal: We don't have an agreement
between polyfill and the browser
... we had product groups inside of MS that needed this
functionality
... we needed client side crypto and all they had was a browser
context
... so we have a client base for library, but that's separate
from the Windows browser
Sounds like a strong case for the polyfill, I'll ask PLH and W3C if they have any opinion
Virginie: Some algorithms will be removed as they are not implemented in two different browsers
Note DH and AES-CTR are also implemented in Mozilla
virginie: If Mozilla can't ship in main browser, then we have to remove it.
PROPOSAL: We can keep it until a few days before, and then we remove it.
virginie: testing on nightly is OK?
hhalpin: Yes, it varies by working group
its OK in our case
but he really does want things without two interoperable implementions he wants removed
virginie: What should we do with
these?
... NUMS and Curve 25519 were not reviewed extensively
... I would put past algorithms in one note and others a second
note.
bal: My advice is not that's
important for some of these algorithms
... they fail to meet interoperability minimum bar
... the text is present in the CR
... so we won't lose it.
... if we text of other algorithms in a spec
... it might confuse people
... it was also an issue with XML-DSIG
... the big lesson from XML-DSIG, was that to try to get SHA-2
into spec took us 4 years
... we needed all of Suite B
... two years of a IRTF WG hold
... it made spec be less relevant, not fast enough for
industry
... we are going to see a lot more churn in proposed
algorithms
... its going to happen on elliptic curve space, post-quantum
space
... its hitting TLS
+1 keeping post-quantum in mind
scribe: I will assume you want a
clear process
... and to keep people from submitting.
... There are certain national algorithms that may come here
too.
virginie: Would you recommend one spec per algorithm?
bal: That might overload process of W3C
virginie: Removing the stuff is done, but we need to know what to do next.
bal: Let me throw a further
wrench, we've had the 4Q curve that is 2.5 faster than
Curve25519
... lots of interest in performance characteristics
... its always tough to register new algorithms
... in XML-DSIG you could define new identifier and we were
loose with private labels
... none of this is mandatory to implement
... I've found Notes to have limited value
virginie: There is no plan to put
them in our main spec
... the Note is algorithms be implemented
http://www.w3.org/2014/Process-20140801/#revised-cr
bal: If you say "Proposed" then
it could be considered going forward
... if you say "Additional" then its less likely.
... I know there's lots of different opinions on the
registry
... my feeling is we're going to see a lot more things proposed
due to lots of new work
... its not going to be one or two
virginie: What is going to drive
adoption is implementation
... it will be the implementation that reflects the
market
... but maybe not so many implementations
bal: We'll need to try some
things out
... what the engineering parameters will be.
... given NSA just killed P-256 by saying its not part of Suite
B anymore
... thrown EC up in the air a bit
... so what's going on is we're going to be also reflecting
what's happening this of.
"Submitted for Consideration"
bal: It will open it wide up, but not commitment no action
What about DH?
Should we have a third category
or do we put in "Proposed" or "Submitted"
bal: From our experience, theres
clear wins on the ECDH side
... we need a motivating scenario
some crypto libraries let everything in
bal: So I would dump it back in
Proposed
... unless you feel a negative recommendation
I would support putting DH into "Proposed"
and anything else the WG ha agreed on but hasn't - for whatever reason - been implemented.
hhalpin: We're going to ship rather than wait for the crypto-space to be stable
bal: Let's ship this
virginie: We'll be
pragmatic
... and when someone proposes a new algorithm, we'll direct
them to do it
hhalpin: And the only testing will be interop
bal: I think you're correct on
that
... all national standards bodies are pushing for international
standards via ISO
... for examples, these could go into "Proposed"
virginie: What about presence or
absence of algorithms per region?
... that is something we'll have to deal with
... in order to stay pragmatic
bal: National-level interop and
regional restrictions around crypto never came up in
XML-DSIG
... what key lengths you were allowed etc.
... Not a problem I'd try to proactively solve
... if we start proactively adding support, we'll encourage
fractured spaces
... doesn't help interop
... web and physical locality doesn't interact very well
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: hhalpin Inferring ScribeNick: hhalpin Present: joanna engelke bal Regrets: wseltzer Found Date: 12 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/12-crypto-minutes.html People with action items: hhalpin[End of scribe.perl diagnostic output]