RFC 8708 on Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)

2020-02-12 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8708

Title:  Use of the HSS/LMS Hash-Based Signature Algorithm 
in the Cryptographic Message Syntax (CMS) 
Author: R. Housley
Status: Standards Track
Stream: IETF
Date:   February 2020
Mailbox:hous...@vigilsec.com
Pages:  14
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-lamps-cms-hash-sig-10.txt

URL:https://www.rfc-editor.org/info/rfc8708

DOI:10.17487/RFC8708

This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with the Cryptographic Message Syntax (CMS).  In
addition, the algorithm identifier and public key syntax are
provided.  The HSS/LMS algorithm is one form of hash-based digital
signature; it is described in RFC 8554.

This document is a product of the Limited Additional Mechanisms for PKIX and 
SMIME Working Group of the IETF.

This is now a Proposed 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 Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) 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
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Deadline Extended! Call for nominations: RFC Editor model evolution program chairs

2020-02-12 Thread IAB Executive Administrative Manager 
The call for nominations for the RFC Editor model evolution program 
chairs has been extended until Monday, 2020-02-24 at 2000 UTC, in order 
to widen the current applicant pool.

> In response to the recent series of public meetings on the evolution 
> of the RSE role, the IAB recently circulated a proposed charter for a 
> program on evolving the RFC Editor model: 
> .
>  
>  
> As that charter notes, the intent is for this program to be modeled on 
> an IETF working group, using its mailing list to develop and validate 
> consensus among the participants. While there will be an IAB program 
> lead acting as a liaison to the IAB for logistical matters, the IAB is 
> seeking chairs from outside the IAB.  These chairs will set the 
> detailed agenda, manage the program, and call consensus among the 
> participants. The IAB currently expects to appoint two chairs, but may 
> choose three if appropriate.
> 
> If you are interested in serving in this role, please send a short 
> email message to iab-ch...@iab.org and ex...@iab.org with your 
> motivation and information concerning your familiarity with IETF 
> working groups or similar processes. The deadline for volunteering is 
> Monday, 2020-02-24 at 2000 UTC. The IAB will then solicit public 
> comments on the candidates.
> 
> The IAB intends to make a decision on this appointment in time to have 
> the program meet at IETF 107 with these chairs in place.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Update on COVID-19 (coronavirus) and IETF 107 Vancouver

2020-02-12 Thread IETF Executive Director 
Following the decision today by GSMA to cancel Mobile World Congress, the IETF 
Chair and I thought it would be useful to update you on our plans regarding 
COVID-19 (coronavirus) and IETF 107 Vancouver.  

At this stage we are still going ahead with the meeting as planned and we are 
not considering cancellation. The situation remains very fluid and so we will 
continue to monitor public health guidelines, particularly those relating to 
global events. Our preference is to follow those rather than set our own 
policy. We will provide further updates as the situation develops.

As a reminder, anyone who is unable to travel to the meeting due to travel 
restrictions will be eligible for a full refund of meeting registration fees. 

More information about the meeting is available at: 
https://www.ietf.org/how/meetings/107/

Please feel free to contact me directly if you have any questions or concerns.

-- 
Jay Daley
IETF Executive Director

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Last Call: (Evaluating Congestion Control for Interactive Real-time Media) to Informational RFC

2020-02-12 Thread The IESG 


The IESG has received a request from the RTP Media Congestion Avoidance
Techniques WG (rmcat) to consider the following document: - 'Evaluating
Congestion Control for Interactive Real-time Media'
   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
last-c...@ietf.org mailing lists by 2020-02-26. 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


   The Real-time Transport Protocol (RTP) is used to transmit media in
   telephony and video conferencing applications.  This document
   describes the guidelines to evaluate new congestion control
   algorithms for interactive point-to-point real-time media.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ballot/


No IPR declarations have been submitted directly on this I-D.




___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Moved to Historic: RFC 4407 on Purported Responsible Address in E-Mail Messages

2020-02-12 Thread rfc-editor 
RFC 4407 has been reclassified as Historic.

RFC 4407

Title:  Purported Responsible Address in E-Mail 
Messages 
Author: J. Lyon
Status: Historic
Stream: IETF
Date:   April 2006
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-lyon-senderid-pra-01.txt

URL:https://www.rfc-editor.org/info/rfc4407

DOI:10.17487/RFC4407

This document defines an algorithm by which, given an e-mail message,
one can extract the identity of the party that appears to have most
proximately caused that message to be delivered.  This identity is
called the Purported Responsible Address (PRA).This memo defines an 
Experimental Protocol for the Internet community.  


HISTORIC: This memo defines a Historic Document 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
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Moved to Historic: RFC 4406 on Sender ID: Authenticating E-Mail

2020-02-12 Thread rfc-editor 
RFC 4406 has been reclassified as Historic.

RFC 4406

Title:  Sender ID: Authenticating E-Mail 
Author: J. Lyon,
M. Wong
Status: Historic
Stream: IETF
Date:   April 2006
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-lyon-senderid-core-01.txt

URL:https://www.rfc-editor.org/info/rfc4406

DOI:10.17487/RFC4406

Internet mail suffers from the fact that much unwanted mail is sent
using spoofed addresses -- "spoofed" in this case means that the address
is used without the permission of the domain owner.  This document
describes a family of tests by which SMTP servers can determine
whether an e-mail address in a received message was used with the
permission of the owner of the domain contained in that e-mail
address.  This memo defines an Experimental Protocol for the Internet community.


HISTORIC: This memo defines a Historic Document 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
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Moved to Historic: RFC 4405 on SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message

2020-02-12 Thread rfc-editor 
RFC 4405 has been reclassified as Historic.

RFC 4405

Title:  SMTP Service Extension for Indicating 
the Responsible Submitter of an E-Mail 
Message 
Author: E. Allman,
H. Katz
Status: Historic
Stream: IETF
Date:   April 2006
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-katz-submitter-01.txt

URL:https://www.rfc-editor.org/info/rfc4405

DOI:10.17487/RFC4405

This memo defines an extension to the Simple Mail Transfer Protocol
(SMTP) service that allows an SMTP client to specify the
responsible submitter of an e-mail message.  The responsible
submitter is the e-mail address of the entity most recently
responsible for introducing a message into the transport stream.
This extension helps receiving e-mail servers efficiently determine
whether the SMTP client is authorized to transmit mail on behalf of
the responsible submitter's domain.  This memo defines an Experimental Protocol 
for the Internet community.


HISTORIC: This memo defines a Historic Document 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
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Discovering Provisioning Domain Names and Data' to Proposed Standard (draft-ietf-intarea-provisioning-domains-11.txt)

2020-02-12 Thread The IESG 
The IESG has approved the following document:
- 'Discovering Provisioning Domain Names and Data'
  (draft-ietf-intarea-provisioning-domains-11.txt) as Proposed Standard

This document is the product of the Internet Area Working Group.

The IESG contact persons are Éric Vyncke and Suresh Krishnan.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/





Technical Summary

A provisioning domain (PVD) is defined as the consistent set of
network configuration information allowing a node to make use of
a network (RFC 7556 Section 2).

This document defines a mechanism for explicitly identifying PVDs
through a Router Advertisement (RA) option.  This RA option announces
a PVD identifier, which hosts can compare to differentiate between
PVDs.  The option can directly carry some information about a PVD and
can optionally point to additional PVD information that can be
retrieved using HTTP over TLS.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

There were two key discussions about the PVD Option that informed the
design.

First: all necessary (non-optional) data for making consistent use of
a network (PVD information) must be transmitted atomically. Use of
existing RA header and options support this (i.e. PIO, RIO, RDNSS).
The atomicity of receiving the minimum required set of information
helped establish that there would be no dependency loop on the
(supposed to be) optional data.

Second: there should be support for PVD Option-aware and non-aware
clients on the same network. This is the origin of the RA option
encapsulating format.

Personnel

The Document Shepherd is Erik Kline .

The Responsible Area Director is Suresh Krishnan .

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce