JOSE WG - IETF 85 Agenda ======================== Wednesday, 7 November 2012, 900-1130 EDT (1400 - 1630 UTC) ****************************************************************************************** JWA, JWE, JWK, JWS Document Updates ****************************************************************************************** John Bradley presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-4.pdf). No questions or comments. ****************************************************************************************** JWS, JWE, JWA, JWK Way forward ****************************************************************************************** Nat Sakimura presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-1.pptx). Richard Barnes: One might observe that requiring all fields to be critical and requiring a nonce invites abuse. Process-wise, should revisit these after some other discussions. ********Algorithm issue******** Jim Schaad: Heard interesting presentation during KITTEN, they were discussing requirements for supporting Suite B in Kerberos. Though shalt not SHA1 anything. Even though there are no known issues with HMAC-SHA1, it is not permitted by a Suite B version of the system, this may or may not cause changes here. This is potentially a good time to ask W3C to implement the specs. John Bradley: Same point, for Suite B if OAEP w/ SHA1 were made mandatory then folks would get into scenario where could not be Suite B and JOSE compliant. Having it available for use but omitted in government implementations should be fine. The debate is still open. Probably not going to see the world agree on an OAEP variant. Joe Hillenbrand: One thing discussed early on was to select small number of things to increase interoperability. Not suggesting things be nailed down to one, but if we are going to pick one mandatory to implement make it Suite B compatible. Richard: Thought we were not going to have mandatory to implement algs. The alg definitions in the web crypto spec allow for separate specification of params to OAEP. That spec is not finalized but that is current state. Stefan Santesson: Really really bad for protocol to specify mandatory to implement algs. Joe: Having users define their own MTI makes sense but guidance can be provided to help make choices. Mike Jones: Background info about how the specs currently handle the status of whether some things are required, optional or deprecated. Illustrious AD Sean suggested that practice be followed where a field is added to the registry for algorithms and explicitly give designated experts to change status over time as crypto landscape changes. There will be initial values, but fully expected that some new algs will be added, downgraded, etc. Not in an inflexible situations. Additionally, always part of JOSE to create interoperable specs. Which is why the question keeps coming up about PKCS1.5. Should OAEP be supported at all, use default in RFC 3347 or do something else. Studies of existing libraries indicate that this is the only feasible choice today. Would like to see this issue put to bed. Richard: If MTI question is to be pursued, should it be run to ground now or flagged as issue. Karen O'Donoghue: Flag as an issue. Stefan: Secdir may define a document with IETF wide algorithm statements. Would be a good approach even if not fitting the timeframe for this group. Sean Turner: Suite B does not define RSA for signature stuff, so perhaps we should just let it be. Karen: Any objections? No. Will take to list for closure. On to criticality of fields. ********Criticality issue******** Richard: If we do not allow non-critical fields we invite folks to stuff things into critical fields that don't really fit. There are some syntactic ways to support non-critical fields. NC fields is a good idea. Jim: Question about bullet 2 on criticality slide. Can you tell me why mandating applications to decide which fields are critical would not provide same security levels. John: the receiver must understand what it is being sent. Sender may have a different understanding than receiver. Jim: Application should define in a specification to address understanding mismatch. Lets it live outside of the core spec. John: It may be possible to leave to all things that use the JOSE specs but thinks this would lead to interop issues. Hannes Tschofenig: If you think about the usage of these, different apps have very different semantics and require specs anyway. So there is no additional security problem with leaving decision to apps. For example, S/MIME defines different CMS fields than other apps. John: Agrees with Richard that if multiple things are using these specs, all may need a way to indicate non-critical elements. We will wind up with interop issues otherwise. Can't assume isolation between apps, for example SAML tokens. Hannes: Richard: We will encode it all in DER:-) Some of the suggestions on the list have been to make two buckets instead of one (critical and non-critical instead of just critical). Mike: A number of syntaxes have been proposed. For example, include a list of fields that may be allowed to be not understood. John: Mike is saying, that no one is expressing the opinion that all fields are non-critical. Everyone agrees that at least some fields should be critical but no one is saying all should be critical. Though there may be some folks who hold this opinion (i.e. all critical). Mike: List traffic indicated there were people who held this view. Simplicity is one reason. Code can simply look at each field, ask do I understand it, fail if not. Alternative is inventing a mechanism for per field behavior. Joe: We've had good success with forward compatibility. If you've updated one side but not the other, its tough to know what to send if sending something new breaks the other side. Mike said from the floor that this argues not to send it. However, this inhibits future change. If we think we won't need different params in the future fine, but that's probably not the case. John: Disagrees with Mike since other protocols will need to include different information into the headers for different reasons, including encrypted body. Saying everything in headers must be understood is going to far. Sean: Conservative in sending, liberal in receiving. Are we sure we have everything we'll need identified? Jim: It is just as simple to pass in a list of headers that the application understands to make applications responsible instead of libraries. Matt Miller: Should not make everything mandatory. In XMPP, we include a rough timestamp. It works for XMPP but won't work for most cases. Thus some headers need to be non-critical. Need not be in the protocol, could be app specified. Mike: Not philosophically opposed to having a list of fields that indicate fields to ignore. To Jim's point about apps defining such, the current spec is completely agnostic to that. As long as app understands, spec allows it to be used. Karen: Before we spend more time, if there is a small group that could work with Mike to make the change could a solution be reached? Perhaps with Richard and John. Mike: Perfectly willing to write up something. Stefan: Is there a thought that the header fields might be expanded in the future. Karen: Uncomfortable precluding expansion. So we've decided all fields are non critical and will figure out right text offline. ********Nonce issue******** Jim: I have proposed a means for putting a timestamp parameter in. Got a number of comments "but do you have a concrete reason for needing this parameter"? If you don't, there is no reason to include a time of signing parameter. Without a use case, acceptance was thin. Not sure what should be done with the proposal. Hannes: There a couple of different aspects. Does not matter if defined now or later. Apps will define new stuff anyway. Where should you put it - header or body? Also does not matter since it needs to be signed. Gets to question how much stuff into base specs and how much into applications. Should not be too religious as it does not matter at the end of the day. John: Since we will resolve the criticality issue, this is less important. Need to determine if multiple folks will need it. Joe: Seems reasonable that more than one app will want protection against replay. Mike: Not disagreeing. Restating some comments from the list, folks who have implemented this at Google and elsewhere, if you don't have an expiration with a nonce then you are implying infinite storage. Jim: The proposal had no nonce and was strictly a time. However, given resolution to previous item then this is less important at this time. Karen: Will take this issue up later. It will not impact WGLC decision. Three issues coming in. WGLC will be discussed at the end. ****************************************************************************************** JOSE Use Case Document ****************************************************************************************** Richard Barnes presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-2.pdf). Jim: Would support adopting this as a WG item. Matt: I also think this would be a good document to adopt. Karen: Any objections. None. Will be adopted. Sean: Procedural point. Will need to re-charter since charter limits the number of docs. Should be easy to address. ****************************************************************************************** Serialization Documents ****************************************************************************************** Mike Jones presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-3.pptx). Richard/Mike: Matt: Re: XMPP, know who is being sent to but not which end point is receiving. Mike: Fair point. May want to distribute cipher text before knowing which key. Matt: In XMPP, this always occurs. Sean: Recharter or stick this stuff into existing docs? Recharter should be easy. Jim: Prefer us to recharter or include in docs? Sean: Publish docs. John: If the right structure is to have as separate doc, we should not let charter issue get in the way. Karen: For purpose of today, consensus is to adopt as separate docs. Will worry about charter later. Richard: Aside from process points, current docs are not a good starting point. ****************************************************************************************** Wrapped Keys ****************************************************************************************** Matt Miller presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-7.pdf). Richard: This is a great idea. We have JWE with key mgmt mech and makes sense to use it. Proposal 2 is the right way to go. Proposal 1 is riddled with issues. All sorts of questions about which algs to use. Much cleaner to use Proposal 2. Jim: You mentioned integrity. Are you doing two separate integrity checks on original msg and key exchange? Matt: Yes. John: My understanding is that the initial message is JWE but recipient does not have decryption key yet. Recipient can ask for the key. Backwards to what usually happens. Mike: Is there concrete syntax for proposal 2? Matt: Yes, previous two slides. Strawman syntax at present. Mike: Different thing from JWK. Jim: Procedure question. How will strawman get incorporated into one or more docs? Matt: Will prepare a draft or work with Mike to see if changes can be made directly to JWK. Mike: Gut reaction is to see individual draft first. Short draft is fine. Matt: OK. Jim: Anyone else to scream and yell? No. A draft will be prepared for group review. ****************************************************************************************** SPI ****************************************************************************************** Richard Barnes presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-6.pdf). John: I don't hate it. Observes that in Open ID connect pre-negotiation occurs. Would not want to remove the ability to specify params in each message. For typical case, the two parties will have negotiated out of band and this will save a pile of octets. Joe: Likes the idea. Did you mean random for spi name? Or something like a UUID? Or something like a hash. John: Probably protocol dependent. Richard: No randomness requirements. Probably some uniqueness requirements, within some scope. John: Will need to determine if sender is identified separately or if uniqueness is global, but this can be sorted out. Matt: This will be application dependent. Richard: Proposes this go in as text to JWS and JWE. Will provide text to Mike. Karen: Anyone against this? No. Are folks comfortable with Richard and Mike working to modify the base docs? John: Would prefer to see a short draft before mucking with base docs. Richard: Probably not a draft, but an email. ****************************************************************************************** Key Requets from W3C ****************************************************************************************** Mike Jones presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-5.pptx) John: As I recall, initial hesitation was with public keys risk of disclosure is small, but with private keys we are taking on large expansion in responsibility. Somewhat hesitant but this is going to be done anyway so we should best grapple with it. Potential for getting it wrong is dire. Justin ?: Add support for it. Add another use case: configuration of bare keys in apps. Would like to use JSON based formats for storing raw keys and not have to do and create a certificate. Ryan Sleevi: If the WG does not adopt this, then the Wc3 work will pursue it since use cases demand such. JOSE seems to be the consistent place to do this work. If JOSE rejects, then WebCrypto group will standardize. Joe: Have always wanted this. Overjoyed to have use cases for this. Thinks the WG is good place to do the work. Enthusiastically supports. Matt: Earlier presentation was argument for wrapped sym key, as others have said private key piece would be useful. Thinks security issues can be addressed and not made worse. Jim: Has not read the draft, puzzled what it is that is required for symmetric key usage? Do you want algs as well since key is just a base64 string. Mike: Yes. Would identify the algorithm and key blob. Analogous to X.509 SubjectPublicKeyInfo. Richard: A couple of desires: 1) wrapped key format for import/export; 2) keys that have attributes attached. Mike: Already have key ID. Could define more. Jim: Clarifying if attributed private key is desired. Are you proposing that we accept as a work item, protection mechanisms. Mike: No request so far. Joe: I am making that request. Necessary to have complete suite. John: Violently opposed to doing the work without protection mechanisms. Sean: Procedurally, nice that it went this route instead of through liaison process. John: Not making comparisons to previous attempts by IETF to define alternatives to X.509. Karen: Will address under rechartering discussion. ****************************************************************************************** Private Key Formats ****************************************************************************************** Mike Jones presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-8.pptx). Richard: Should merge this with the stuff Matt talked about earlier. May make sense to address in JWK. Matt: Need to write drafts first and see what they look like. Multiple docs may make things more readable. Joe: Have you defined a protection mechanism yet? Mike: No John: Agree that Matt is pushing private keys around and needs protection. Wrapped symmetric key more specifically, Lots of overlap with this. Joe: Start with an email to the list describing the overall architecture. Here are the pieces, how they fit, etc. Let's see it at least in high level form then decide how to best allocate to documents. Mike: Three layers: public key, key representations for private and symmetric keys, key protection mechanisms. ****************************************************************************************** Re-chartering questions ****************************************************************************************** Sean: The milestones are separate from charter so just send an email with new dates. Karen: Back to WGLC questions. One open issue on criticality of headers: Richard, John and Mike will address. Private key work and SPI work effect core docs. Jim: Richard, would you like to have mandatory to implement (MTI) algorithm argument now? Richard: Sure. The broad outline is whether these specs should require a given set of algs. A similar arg went through WC3 web crypto group. They decided against. Argument in favor is interoperability. Counter view is placing alg requirements makes it hard for apps to make sure certain algorithms are available. For example, multi-platform browsers that use OS crypto. Jim: Make clear, IESG will complain if there is not a mandatory to implement alg. May be able to get away with pushing to application. Richard: Yes. CMS and PKIX do not have required algs. This is not DNSSEC which is a global infrastructure. In this case, the communications are between two parties who can figure out what they want to do. Mike: Every draft for last two years has had some set of MTI algs. Having a small core helps. Request is that if we are changing, there should be a consensus call. Change is a fairly big deal. Re: Web crypto decision, their use case is different. In our case, a small set of algs is proposed to promote interop. They are defining general purpose low level mechanism. Russ Housley: Interop is the whole point with MTI. However, algs will change over time. Do not put this in base spec. We have made that mistake before, don't repeat. Reason PKIX does not have MTI alg is that certs are used in many apps. Each app defines MTI achieving separation of MTI from syntax. Barry Leiba: Would rather see MTI in registrations of these things. Appreciates that apps should define. Given reuse of apps, there is concern about not stating something. (from floor) use case? No use case, just thinking ahead. Mike: The spec initializes a set of use, don't use, etc in a registry. Russ: Please don't confuse a registry with MTI. Richard: Re: cross-app usage, for interop there are often specs to iron out details anyway. Just another detail in those. Joe: Fine with punting to apps. For example, for XMPP these are MTI, etc. Karen: So, hearing generally agreement to move out of base spec except from Mike. AD has asked to do a hum then will take it to a list. Hum indicates remove from base spec wins. Will bring up on the list. There are four open issues. Another rev of docs will be required before WGLC. How long will it take to rev drafts? Richard and Matt? Richard: SPI should be quick. By end of year. Matt: For draft of wrapped keys. Similar time frame. Integrating with others is a different discussion. Mike: Private key, wrapped key, etc. is much bigger chunk of work. Would like JWK go to WGLC sooner. Jim: Does current JWK define anything about field criticality? Mike: Follows other docs. Jim: So we need a rev for that too. Richard: Matt's private key bits should just be shuffling stuff between docs. Should not be large effort. Karen: I though W3C work would take longer. Jim: Opposed to including private keys with a doc describing protection. Sean: Would like to see this work taken on. Karen: A few issues to incorporate. Aim is to issue WGLC in early 2013. Mike: Assuming we make decisions on these issued before WGLC, chairs should assume a consensus call will be held on the list. Jim: I assume you preference would be to update JWA and JWK specs to include private keys? Mike: I would prefer to go forward with public key docs as is and write a new draft that would update and add fields to JWK structure but in a separate draft for private, sym and wrapped keys. Richard: I think I would split todos into piles: 1) things that go into a JWE; 2) things like private keys, sym keys and attributes. Push wrapped keys into JWK. Provide feedback to W3C as well. Mike: I have a different model of what JWK is for vs Richard. JWK is just a key representation. If you want to wrap it, that's a different object that uses JWK. It's not a part of the key but a container. Would write container separately. Richard: JWK defines how to send keys on the wire. Joe: Would be nice to have one short email with architecture. Too early to say how docs will be split. Leave that out of new charter. Karen: Who is going to write architecture email. Joe: Mike nodded in a way that indicated he may do that. Mike: OK, if I get some input on best practices for wrapped keys. Joe: Let's find a white board this week, then send notes from that board to the list. Karen: Strongly agree. Joe: I will fill the whiteboard. Karen: Next thing is use cases doc. Charter will be updated. Ditto serialization draft, which will be incorporated somehow. Charter will be updated for this as well. Final is W3C work will be documented in email generated by the white board team. Anything else? Jim: Joe, do you want volunteers? Joe: Sending note to the list right now. Matt: One thing that has come up on the list is key derivation stuff. Some disalignment with NIST 800-56a. PBKDF2 as defined says a password is an octet string. Mike: Primary thing in specs, is to address legitimate concerns about use of concat KDF. Initially no length prefix. So there was ambiguity. With length prefix, ambiguity is gone. What is it possible for everyone to easily implement? With concat, it's a string concat and a hash. Everyone can do that. At least 6 implementations. Richard: Are we actually saving anything. Are we sending more info to identify KDF than if we just sent key, since KDF is intended to allow use of shorter keys. Mike: You do need KDF for ECDH anyway. Anything with key agreement will have KDF already. Matt: In that case, implementing PBKDF is not much more difficult. Mike: Iterations are just more work. Jim: Iterations can be set to 1. Matt: Looking at things that do PBKDF and concat KDF, it's not hard to implement PBKDF. ?: Is subject KDFs or password based KDFs? Jim: KDFs ?: Don't we have a real KDF? Why not use that? Lots of work going on about improving PBKDFs. Not sure marrying to PBKDF2 is wise. Matt: Not saying we only implement PBKDF2, saying for things we register don't see why not PBKDF2. Mike: Given decision to specify AEAD, there's nothing to say you could not define another alg, say CBC with a different KDF. Various iterations with ADs etc to make sure use of concat is clean. Same issues would come up for any other KDF. Similar sets of inputs. Not any simpler to use different KDF. Matt: Richard: Our need to have this discussion is a consequence of alg IDs. If alg ID included this things then this would not be an issue. May want to figure out how to separate this out to be more configurable. Mike: That's a closed issue. Karen: Issuer tracker will be used going forward. Read the docs now and get comments out now to spare work during WGLC. Kevin Igoe: There is a draft that does composite AEAD . May want to look at that. Mike: WG did have a presentation last time. Discussion was that it is an alg that could be added should it mature. Kevin: Why not just steal their params? Mike: There was a length expansion there that we don't need. Richard: Please post to the list how using a longer key compares to using a KDF.