WG Review: Javascript Object Signing and Encryption (jose)
The Javascript Object Signing and Encryption (jose) working group in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-04-23. Javascript Object Signing and Encryption (jose) Current Status: Active Working Group Chairs: Karen O'Donoghue odonog...@isoc.org Jim Schaad i...@augustcellars.com Assigned Area Director: Sean Turner turn...@ieca.com Mailing list Address: j...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: http://www.ietf.org/mail-archive/web/jose/ Charter of Working Group: JavaScript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services for JSON with encryption, digital signatures, and message authentication codes (MACs). Different proposals for providing such security services have already been defined and implemented. This Working Group will standardize the mechanism for integrity protection (signature and MAC) and encryption as well as the format for keys and algorithm identifiers to support interoperability of security services for protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is sound. The WG will strive to gather use cases to ensure the broadest possible applicability of the mechanism. As JSON adoption expands, the different applications utilizing JSON security services will grow and this leads to the need to support different requirements. The WG will develop a generic syntax that can be used by applications to secure JSON-data, but it will be up to the application to fully specify the use of the WG's documents much the same way S/MIME is the application of CMS to MIME-based media types. This group is chartered to work on the following deliverables: (1) A Standards Track document or documents representing integrity-protected data using JSON-based data structures, including (but not limited to) JSON data structures. Integrity protection includes public-key digital signatures as well as symmetric-key MACs. (2) A Standards Track document or documents representing encrypted data using JSON-based data structures, including (but not limited to) JSON data structures. (3) A Standards Track document specifying how to encode public keys as JSON- structured objects. (4) A Standards Track document specifying algorithms and algorithm identifiers for the previous three documents. (5) A Standards Track document specifying how to encode private and symmetric keys as JSON-structured objects. This document will build upon the concepts and structures in (3). (6) A Standards Track document specifying a means of protecting private and symmetric keys via encryption. This document will build upon the concepts and structures in (2) and (5). This document may register additional algorithms in registries defined by (4). (7) An Informational document detailing Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). (8) An Informational document that tells an application what needs to be specified in order to implement JOSE. One or more of these goals may be combined into a single document, in which case the concrete milestones for these goals will be satisfied by the consolidated document(s). Milestones: Jan 2012 - Submit JSON object integrity document as a WG item. Jan 2012 - Submit JSON object encryption document as a WG item. Jan 2012 - Submit JSON key format document as a WG item. Jan 2012 - Submit JSON algorithm document as a WG item. Jun 2012 - Start Working Group Last Call on JSON object integrity document. Jun 2012 - Start Working Group Last Call on JSON object encryption document. Jun 2012 - Start Working Group Last Call on JSON key format document. Jun 2012 - Start Working Group Last Call on JSON algorithm document. Jul 2012 - Submit JSON object integrity document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON object encryption document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON algorithm document to IESG for consideration as Standards Track document.
WG Review: IMAP QRESYNC Extension (qresync)
A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-04-23. IMAP QRESYNC Extension (qresync) Current Status: Proposed Working Group Assigned Area Director: Barry Leiba barryle...@computer.org Mailing list Address: imap...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/imapext Archive: http://www.ietf.org/mail-archive/web/imapext/ Charter of Working Group: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for accessing email messages on a server that implements a message store from a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another. Base IMAP as described in RFC 3501 requires that in order to discover flag changes and expunged messages in a mailbox, the client has to fetch flags for all messages it knows in the mailbox and compare returned results with its own state. This can generate a significant amount of traffic for big mailboxes. The IMAP CONDSTORE extension (RFC 4551) provides a facility for IMAP clients to quickly resynchronize mailbox flag changes in a mailbox. The IMAP QRESYNC extension (RFC 5162) extends CONDSTORE to also cover expunged messages, and reduces the number of round trips needed to resynchronize by extending the SELECT/EXAMINE command. The CONDSTORE and QRESYNC extensions are deployed in both clients and servers. These deployments have exposed errors and clarity issues in the specifications, and they need correcting. The IMAP QRESYNC Extension working group has the task of updating CONDSTORE and QRESYNC extensions on the Standards Track. The working group might produce one (combined) or two separate documents (as now) updating these extensions. The working group will review errata and update the documents as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes at this stage to a minimum and avoid incompatible changes. No other IMAP extension work is in scope for this working group. Milestones: TBD
Last Call: draft-ietf-oauth-revocation-07.txt (Token Revocation) to Proposed Standard
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Token Revocation' draft-ietf-oauth-revocation-07.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-04-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ No IPR declarations have been submitted directly on this I-D. The draft has a normative reference to RFC2246 (as well as 5346) as it follows the same approach to TLS as the base oauth spec. (RFC6749, section 1.2).
RFC 6912 on Principles for Unicode Code Point Inclusion in Labels in the DNS
A new Request for Comments is now available in online RFC libraries. RFC 6912 Title: Principles for Unicode Code Point Inclusion in Labels in the DNS Author: A. Sullivan, D. Thaler, J. Klensin, O. Kolkman Status: Informational Stream: IAB Date: April 2013 Mailbox:asulli...@dyn.com, dtha...@microsoft.com, john-i...@jck.com, o...@nlnetlabs.nl Pages: 12 Characters: 27078 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-iab-dns-zone-codepoint-pples-02.txt URL:http://www.rfc-editor.org/rfc/rfc6912.txt Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone. This document is a product of the Internet Architecture Board. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: draft-saintandre-impp-call-info-02.txt (Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)' draft-saintandre-impp-call-info-02.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-05-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines and registers a value of impp (instant messaging and presence protocol) for the purpose header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). The file can be obtained via http://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/ballot/ No IPR declarations have been submitted directly on this I-D.
IETF Nominations Committee Chair
IETF community, One of the roles you entrusted to the Internet Society (ISOC) President CEO, to be fulfilled through consultation with the IETF community, is the appointment of the IETF Nominations Committee chair. It gives me great pleasure to announce that Allison Mankin has agreed to serve as the 2013 - 2014 IETF Nominations Committee chair. Allison served a total 10 years as a TSV AD, most recently 2000-2006. She currently serves on the Transport Directorate and is the liaison to ISO JTC1/SC6. Allison has co-chaired several Working Groups including RMT and Geopriv, and going back even further she co-directed the IPng Selection process. The NomComm process is central to the IETF's success, and it is important that it have robust support. A Call for Nominations for this committee will be sent to the IETF Announcement list; and a list of the IESG, IAB and IAOC/IETF Trust seats to be filled will be published shortly. Please give serious consideration to volunteering for the Nominations Committee as well as to possible candidates for the open positions. In the interim, feel free to make your suggestions known to Allison, who will share them with the committee once it is seated. Allison can be reached at: Allison Mankin aman...@verisign.com. Thank you in advance for your support and a sincere thank you to Allison for agreeing to take on this very significant responsibility. Regards, Lynn St. Amour President CEO, Internet Society (ISOC)
Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The Internet Numbers Registry System' draft-housley-rfc2050bis-01.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-05-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. This document does not propose any changes to the Internet Numbers Registry System. The file can be obtained via http://datatracker.ietf.org/doc/draft-housley-rfc2050bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-housley-rfc2050bis/ballot/ No IPR declarations have been submitted directly on this I-D.
STD 75, RFC 6891 on Extension Mechanisms for DNS (EDNS(0))
A new Request for Comments is now available in online RFC libraries. STD 75 RFC 6891 Title: Extension Mechanisms for DNS (EDNS(0)) Author: J. Damas, M. Graff, P. Vixie Status: Standards Track Stream: IETF Date: April 2013 Mailbox:j...@bondis.org, explo...@flame.org, vi...@isc.org Pages: 16 Characters: 32856 Obsoletes: RFC 2671, RFC 2673 See Also: STD 75 I-D Tag:draft-ietf-dnsext-rfc2671bis-edns0-10.txt URL:http://www.rfc-editor.org/rfc/rfc6891.txt The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 (Binary Labels in the Domain Name System) and adds considerations on the use of extended labels in the DNS. This document is a product of the DNS Extensions Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
BCP 42, RFC 6895 on Domain Name System (DNS) IANA Considerations
A new Request for Comments is now available in online RFC libraries. BCP 42 RFC 6895 Title: Domain Name System (DNS) IANA Considerations Author: D. Eastlake 3rd Status: Best Current Practice Stream: IETF Date: April 2013 Mailbox:d3e...@gmail.com Pages: 19 Characters: 38979 Obsoletes: RFC 6195 Updates:RFC 1183, RFC 2845, RFC 2930, RFC 3597 See Also: BCP 42 I-D Tag:draft-ietf-dnsext-rfc6195bis-05.txt URL:http://www.rfc-editor.org/rfc/rfc6895.txt This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. This document is a product of the DNS Extensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
