1 Internet Engineering Task Force (IETF)                        P. Wouters   
    2 Request for Comments: 7929                                       Red Hat   
    3 Category: Experimental                                       August 2016   
    4 ISSN: 2070-1721                                                            
    5                                                                            
    6                                                                            
    7  DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP    
    8                                                                            
    9 Abstract                                                                   
   10                                                                            
   11    OpenPGP is a message format for email (and file) encryption that        
   12    lacks a standardized lookup mechanism to securely obtain OpenPGP        
   13    public keys.  DNS-Based Authentication of Named Entities (DANE) is a    
   14    method for publishing public keys in DNS.  This document specifies a    
   15    DANE method for publishing and locating OpenPGP public keys in DNS      
   16    for a specific email address using a new OPENPGPKEY DNS resource        
   17    record.  Security is provided via Secure DNS, however the OPENPGPKEY    
   18    record is not a replacement for verification of authenticity via the    
   19    "web of trust" or manual verification.  The OPENPGPKEY record can be    
   20    used to encrypt an email that would otherwise have to be sent           
   21    unencrypted.                                                            
   22                                                                            
   23 Status of This Memo                                                        
   24                                                                            
   25    This document is not an Internet Standards Track specification; it is   
   26    published for examination, experimental implementation, and             
   27    evaluation.                                                             
   28                                                                            
   29    This document defines an Experimental Protocol for the Internet         
   30    community.  This document is a product of the Internet Engineering      
   31    Task Force (IETF).  It represents the consensus of the IETF             
   32    community.  It has received public review and has been approved for     
   33    publication by the Internet Engineering Steering Group (IESG).  Not     
   34    all documents approved by the IESG are a candidate for any level of     
   35    Internet Standard; see Section 2 of RFC 7841.                           
   36                                                                            
   37    Information about the current status of this document, any errata,      
   38    and how to provide feedback on it may be obtained at                    
   39    http://www.rfc-editor.org/info/rfc7929.                                 
   40                                                                            
   41                                                                            
   42                                                                            
   43                                                                            
   44                                                                            
   45                                                                            
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Wouters                       Experimental                      [Page 1]   

   53 RFC 7929                  DANE for OpenPGP Keys              August 2016   
   54                                                                            
   55                                                                            
   56 Copyright Notice                                                           
   57                                                                            
   58    Copyright (c) 2016 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   60                                                                            
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (http://trustee.ietf.org/license-info) in effect on the date of         
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.  Code Components extracted from this document must    
   67    include Simplified BSD License text as described in Section 4.e of      
   68    the Trust Legal Provisions and are provided without warranty as         
   69    described in the Simplified BSD License.                                
   70                                                                            
   71                                                                            
   72                                                                            
   73                                                                            
   74                                                                            
   75                                                                            
   76                                                                            
   77                                                                            
   78                                                                            
   79                                                                            
   80                                                                            
   81                                                                            
   82                                                                            
   83                                                                            
   84                                                                            
   85                                                                            
   86                                                                            
   87                                                                            
   88                                                                            
   89                                                                            
   90                                                                            
   91                                                                            
   92                                                                            
   93                                                                            
   94                                                                            
   95                                                                            
   96                                                                            
   97                                                                            
   98                                                                            
   99                                                                            
  100                                                                            
  101                                                                            
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Wouters                       Experimental                      [Page 2]   

  108 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  109                                                                            
  110                                                                            
  111 Table of Contents                                                          
  112                                                                            
  113    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4   
  114      1.1.  Experiment Goal . . . . . . . . . . . . . . . . . . . . .   4   
  115      1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5   
  116    2.  The OPENPGPKEY Resource Record  . . . . . . . . . . . . . . .   5   
  117      2.1.  The OPENPGPKEY RDATA Component  . . . . . . . . . . . . .   6   
  118        2.1.1.  The OPENPGPKEY RDATA Content  . . . . . . . . . . . .   6   
  119        2.1.2.  Reducing the Transferable Public Key Size . . . . . .   7   
  120      2.2.  The OPENPGPKEY RDATA Wire Format  . . . . . . . . . . . .   7   
  121      2.3.  The OPENPGPKEY RDATA Presentation Format  . . . . . . . .   7   
  122    3.  Location of the OPENPGPKEY Record . . . . . . . . . . . . . .   8   
  123    4.  Email Address Variants and Internationalization                     
  124        Considerations  . . . . . . . . . . . . . . . . . . . . . . .   9   
  125    5.  Application Use of OPENPGPKEY . . . . . . . . . . . . . . . .  10   
  126      5.1.  Obtaining an OpenPGP Key for a Specific Email Address . .  10   
  127      5.2.  Confirming that an OpenPGP Key is Current . . . . . . . .  10   
  128      5.3.  Public Key UIDs and Query Names . . . . . . . . . . . . .  10   
  129    6.  OpenPGP Key Size and DNS  . . . . . . . . . . . . . . . . . .  11   
  130    7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11   
  131      7.1.  MTA Behavior  . . . . . . . . . . . . . . . . . . . . . .  12   
  132      7.2.  MUA Behavior  . . . . . . . . . . . . . . . . . . . . . .  13   
  133      7.3.  Response Size . . . . . . . . . . . . . . . . . . . . . .  14   
  134      7.4.  Email Address Information Leak  . . . . . . . . . . . . .  14   
  135      7.5.  Storage of OPENPGPKEY Data  . . . . . . . . . . . . . . .  14   
  136      7.6.  Security of OpenPGP versus DNSSEC . . . . . . . . . . . .  15   
  137    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15   
  138      8.1.  OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . .  15   
  139    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15   
  140      9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15   
  141      9.2.  Informative References  . . . . . . . . . . . . . . . . .  16   
  142    Appendix A.  Generating OPENPGPKEY Records  . . . . . . . . . . .  18   
  143    Appendix B.  OPENPGPKEY IANA Template . . . . . . . . . . . . . .  19   
  144    Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  20   
  145    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20   
  146                                                                            
  147                                                                            
  148                                                                            
  149                                                                            
  150                                                                            
  151                                                                            
  152                                                                            
  153                                                                            
  154                                                                            
  155                                                                            
  156                                                                            
  157                                                                            
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Wouters                       Experimental                      [Page 3]   

  163 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  164                                                                            
  165                                                                            
  166 1.  Introduction                                                           
  167                                                                            
  168    OpenPGP [RFC4880] public keys are used to encrypt or sign email         
  169    messages and files.  To encrypt an email message, or verify a           
  170    sender's OpenPGP signature, the email client Mail User Agent (MUA) or   
  171    the email server Mail Transfer Agent (MTA) needs to locate the          
  172    recipient's OpenPGP public key.                                         
  173                                                                            
  174    OpenPGP clients have relied on centralized "well-known" key servers     
  175    that are accessed using the HTTP Keyserver Protocol [HKP].              
  176    Alternatively, users need to manually browse a variety of different     
  177    front-end websites.  These key servers do not require a confirmation    
  178    of the email address used in the User ID (UID) of the uploaded          
  179    OpenPGP public key.  Attackers can -- and have -- uploaded rogue        
  180    public keys with other people's email addresses to these key servers.   
  181                                                                            
  182    Once uploaded, public keys cannot be deleted.  People who did not       
  183    pre-sign a key revocation can never remove their OpenPGP public key     
  184    from these key servers once they have lost access to their private      
  185    key.  This results in receiving encrypted email that cannot be          
  186    decrypted.                                                              
  187                                                                            
  188    Therefore, these key servers are not well suited to support MUAs and    
  189    MTAs to automatically encrypt email -- especially in the absence of     
  190    an interactive user.                                                    
  191                                                                            
  192    This document describes a mechanism to associate a user's OpenPGP       
  193    public key with their email address, using the OPENPGPKEY DNS RRtype.   
  194    These records are published in the DNS zone of the user's email         
  195    address.  If the user loses their private key, the OPENPGPKEY DNS       
  196    record can simply be updated or removed from the zone.                  
  197                                                                            
  198    The OPENPGPKEY data is secured using Secure DNS [RFC4035].              
  199                                                                            
  200    The main goal of the OPENPGPKEY resource record is to stop passive      
  201    attacks against plaintext emails.  While it can also thwart some        
  202    active attacks (such as people uploading rogue keys to key servers in   
  203    the hopes that others will encrypt to these rogue keys), this           
  204    resource record is not a replacement for verifying OpenPGP public       
  205    keys via the "web of trust" signatures, or manually via a fingerprint   
  206    verification.                                                           
  207                                                                            
  208 1.1.  Experiment Goal                                                      
  209                                                                            
  210    This specification is one experiment in improving access to public      
  211    keys for end-to-end email security.  There are a range of ways in       
  212    which this can reasonably be done for OpenPGP or S/MIME, for example,   
  213    using the DNS, or SMTP, or HTTP.  Proposals for each of these have      
  214                                                                            
  215                                                                            
  216                                                                            
  217 Wouters                       Experimental                      [Page 4]   

  218 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  219                                                                            
  220                                                                            
  221    been made with various levels of support in terms of implementation     
  222    and deployment.  For each such experiment, specifications such as       
  223    this will enable experiments to be carried out that may succeed or      
  224    that may uncover technical or other impediments to large- or small-     
  225    scale deployments.  The IETF encourages those implementing and          
  226    deploying such experiments to publicly document their experiences so    
  227    that future specifications in this space can benefit.                   
  228                                                                            
  229    This document defines an RRtype whose use is Experimental.  The goal    
  230    of the experiment is to see whether encrypted email usage will          
  231    increase if an automated discovery method is available to MTAs and      
  232    MUAs to help the end user with email encryption key management.         
  233                                                                            
  234    It is unclear if this RRtype will scale to some of the larger email     
  235    service deployments.  Concerns have been raised about the size of the   
  236    OPENPGPKEY record and the size of the resulting DNS zone files.  This   
  237    experiment hopefully will give the working group some insight into      
  238    whether or not this is a problem.                                       
  239                                                                            
  240    If the experiment is successful, it is expected that the findings of    
  241    the experiment will result in an updated document for standards track   
  242    approval.                                                               
  243                                                                            
  244    The OPENPGPKEY RRtype somewhat resembles the generic CERT record        
  245    defined in [RFC4398].  However, the CERT record uses sub-typing with    
  246    many different types of keys and certificates.  It is suspected that    
  247    its general application of very different protocols (PKIX versus        
  248    OpenPGP) has been the cause for lack of implementation and              
  249    deployment.  Furthermore, the CERT record uses sub-typing, which is     
  250    now considered to be a bad idea for DNS.                                
  251                                                                            
  252 1.2.  Terminology                                                          
  253                                                                            
  254    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  255    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
  256    document are to be interpreted as described in RFC 2119 [RFC2119].      
  257                                                                            
  258    This document also makes use of standard DNSSEC and DANE terminology.   
  259    See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for      
  260    these terms.                                                            
  261                                                                            
  262 2.  The OPENPGPKEY Resource Record                                         
  263                                                                            
  264    The OPENPGPKEY DNS resource record (RR) is used to associate an end     
  265    entity OpenPGP Transferable Public Key (see Section 11.1 of             
  266    [RFC4880]) with an email address, thus forming an "OpenPGP public key   
  267    association".  A user that wishes to specify more than one OpenPGP      
  268    key, for example, because they are transitioning to a newer stronger    
  269                                                                            
  270                                                                            
  271                                                                            
  272 Wouters                       Experimental                      [Page 5]   

  273 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  274                                                                            
  275                                                                            
  276    key, can do so by adding multiple OPENPGPKEY records.  A single         
  277    OPENPGPKEY DNS record MUST only contain one OpenPGP key.                
  278                                                                            
  279    The type value allocated for the OPENPGPKEY RR type is 61.  The         
  280    OPENPGPKEY RR is class independent.                                     
  281                                                                            
  282 2.1.  The OPENPGPKEY RDATA Component                                       
  283                                                                            
  284    The RDATA portion of an OPENPGPKEY resource record contains a single    
  285    value consisting of a Transferable Public Key formatted as specified    
  286    in [RFC4880].                                                           
  287                                                                            
  288 2.1.1.  The OPENPGPKEY RDATA Content                                       
  289                                                                            
  290    An OpenPGP Transferable Public Key can be arbitrarily large.  DNS       
  291    records are limited in size.  When creating OPENPGPKEY DNS records,     
  292    the OpenPGP Transferable Public Key should be filtered to only          
  293    contain appropriate and useful data.  At a minimum, an OPENPGPKEY       
  294    Transferable Public Key for the user hugh@example.com should contain:   
  295                                                                            
  296              o The primary key X                                           
  297                o One User ID Y, which SHOULD match 'hugh@example.com'      
  298                  o Self-signature from X, binding X to Y                   
  299                                                                            
  300    If the primary key is not encryption-capable, at least one relevant     
  301    subkey should be included, resulting in an OPENPGPKEY Transferable      
  302    Public Key containing:                                                  
  303                                                                            
  304            o The primary key X                                             
  305              o One User ID Y, which SHOULD match 'hugh@example.com'        
  306                o Self-signature from X, binding X to Y                     
  307              o Encryption-capable subkey Z                                 
  308                o Self-signature from X, binding Z to X                     
  309              o (Other subkeys, if relevant)                                
  310                                                                            
  311    The user can also elect to add a few third-party certifications,        
  312    which they believe would be helpful for validation in the traditional   
  313    "web of trust".  The resulting OPENPGPKEY Transferable Public Key       
  314    would then look like:                                                   
  315                                                                            
  316            o The primary key X                                             
  317              o One User ID Y, which SHOULD match 'hugh@example.com'        
  318                o Self-signature from X, binding X to Y                     
  319                o Third-party certification from V, binding Y to X          
  320                o (Other third-party certifications, if relevant)           
  321              o Encryption-capable subkey Z                                 
  322                o Self-signature from X, binding Z to X                     
  323              o (Other subkeys, if relevant)                                
  324                                                                            
  325                                                                            
  326                                                                            
  327 Wouters                       Experimental                      [Page 6]   

  328 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  329                                                                            
  330                                                                            
  331 2.1.2.  Reducing the Transferable Public Key Size                          
  332                                                                            
  333    When preparing a Transferable Public Key for a specific OPENPGPKEY      
  334    RDATA format with the goal of minimizing certificate size, a user       
  335    would typically want to:                                                
  336                                                                            
  337    o  Where one User ID from the certifications matches the looked-up      
  338       address, strip away non-matching User IDs and any associated         
  339       certifications (self-signatures or third-party certifications).      
  340                                                                            
  341    o  Strip away all User Attribute packets and associated                 
  342       certifications.                                                      
  343                                                                            
  344    o  Strip away all expired subkeys.  The user may want to keep revoked   
  345       subkeys if these were revoked prior to their preferred expiration    
  346       time to ensure that correspondents know about these earlier than     
  347       expected revocations.                                                
  348                                                                            
  349    o  Strip away all but the most recent self-signature for the            
  350       remaining User IDs and subkeys.                                      
  351                                                                            
  352    o  Optionally strip away any uninteresting or unimportant third-party   
  353       User ID certifications.  This is a value judgment by the user that   
  354       is difficult to automate.  At the very least, expired and            
  355       superseded third-party certifications should be stripped out.  The   
  356       user should attempt to keep the most recent and most well-           
  357       connected certifications in the "web of trust" in their              
  358       Transferable Public Key.                                             
  359                                                                            
  360 2.2.  The OPENPGPKEY RDATA Wire Format                                     
  361                                                                            
  362    The RDATA Wire Format consists of a single OpenPGP Transferable         
  363    Public Key as defined in Section 11.1 of [RFC4880].  Note that this     
  364    format is without ASCII armor or base64 encoding.                       
  365                                                                            
  366 2.3.  The OPENPGPKEY RDATA Presentation Format                             
  367                                                                            
  368    The RDATA Presentation Format, as visible in master files [RFC1035],    
  369    consists of a single OpenPGP Transferable Public Key as defined in      
  370    Section 11.1 of [RFC4880] encoded in base64 as defined in Section 4     
  371    of [RFC4648].                                                           
  372                                                                            
  373                                                                            
  374                                                                            
  375                                                                            
  376                                                                            
  377                                                                            
  378                                                                            
  379                                                                            
  380                                                                            
  381                                                                            
  382 Wouters                       Experimental                      [Page 7]   

  383 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  384                                                                            
  385                                                                            
  386 3.  Location of the OPENPGPKEY Record                                      
  387                                                                            
  388    The DNS does not allow the use of all characters that are supported     
  389    in the "local-part" of email addresses as defined in [RFC5322] and      
  390    [RFC6530].  Therefore, email addresses are mapped into DNS using the    
  391    following method:                                                       
  392                                                                            
  393    1.  The "left-hand side" of the email address, called the "local-       
  394        part" in both the mail message format definition [RFC5322] and in   
  395        the specification for internationalized email [RFC6530]) is         
  396        encoded in UTF-8 (or its subset ASCII).  If the local-part is       
  397        written in another charset, it MUST be converted to UTF-8.          
  398                                                                            
  399    2.  The local-part is first canonicalized using the following rules.    
  400        If the local-part is unquoted, any comments and/or folding          
  401        whitespace (CFWS) around dots (".") is removed.  Any enclosing      
  402        double quotes are removed.  Any literal quoting is removed.         
  403                                                                            
  404    3.  If the local-part contains any non-ASCII characters, it SHOULD be   
  405        normalized using the Unicode Normalization Form C from              
  406        [Unicode90].  Recommended normalization rules can be found in       
  407        Section 10.1 of [RFC6530].                                          
  408                                                                            
  409    4.  The local-part is hashed using the SHA2-256 [RFC5754] algorithm,    
  410        with the hash truncated to 28 octets and represented in its         
  411        hexadecimal representation, to become the left-most label in the    
  412        prepared domain name.                                               
  413                                                                            
  414    5.  The string "_openpgpkey" becomes the second left-most label in      
  415        the prepared domain name.                                           
  416                                                                            

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15

This RFC is implemented in BIND 9.18 (all versions).

  417    6.  The domain name (the "right-hand side" of the email address,        
  418        called the "domain" in [RFC5322]) is appended to the result of      
  419        step 2 to complete the prepared domain name.                        
  420                                                                            
  421    For example, to request an OPENPGPKEY resource record for a user        
  422    whose email address is "hugh@example.com", an OPENPGPKEY query would    
  423    be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35   
  424    eec8f72e57f9eec01c1afd6._openpgpkey.example.com".  The corresponding    
  425    RR in the example.com zone might look like (key shortened for           
  426    formatting):                                                            
  427                                                                            
  428    c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>     
  429                                                                            
  430                                                                            
  431                                                                            
  432                                                                            
  433                                                                            
  434                                                                            
  435                                                                            
  436                                                                            
  437 Wouters                       Experimental                      [Page 8]   

  438 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  439                                                                            
  440                                                                            
  441 4.  Email Address Variants and Internationalization Considerations         
  442                                                                            
  443    Mail systems usually handle variant forms of local-parts.  The most     
  444    common variants are upper- and lowercase, often automatically           
  445    corrected when a name is recognized as such.  Other variants include    
  446    systems that ignore "noise" characters such as dots, so that local-     
  447    parts 'johnsmith' and 'John.Smith' would be equivalent.  Many systems   
  448    allow "extensions" such as 'john-ext' or 'mary+ext' where 'john' or     
  449    'mary' is treated as the effective local-part, and 'ext' is passed to   
  450    the recipient for further handling.  This can complicate finding the    
  451    OPENPGPKEY record associated with the dynamically created email         
  452    address.                                                                
  453                                                                            
  454    [RFC5321] and its predecessors have always made it clear that only      
  455    the recipient MTA is allowed to interpret the local-part of an          
  456    address.  Therefore, sending MUAs and MTAs supporting OPENPGPKEY MUST   
  457    NOT perform any kind of mapping rules based on the email address.  In   
  458    order to improve chances of finding OPENPGP RRs for a particular        
  459    local-part, domains that allow variant forms (such as treating local-   
  460    parts as case-insensitive) might publish OPENPGP RRs for all variants   
  461    of local-parts, might publish variants on first use (for example, a     
  462    webmail provider that also controls DNS for a domain can publish        
  463    variants as used by owner of a particular local-part) or just publish   
  464    OPENPGP RRs for the most common variants.                               
  465                                                                            
  466    Section 3 above defines how the local-part is used to determine the     
  467    location where one looks for an OPENPGPKEY record.  Given the variety   
  468    of local-parts seen in email, designing a good experiment for this is   
  469    difficult, as: a) some current implementations are known to lowercase   
  470    at least US-ASCII local-parts, b) we know from (many) other             
  471    situations that any strategy based on guessing and making multiple      
  472    DNS queries is not going to achieve consensus for good reasons, and     
  473    c) the underlying issues are just hard -- see Section 10.1 of           
  474    [RFC6530] for discussion of just some of the issues that would need     
  475    to be tackled to fully address this problem.                            
  476                                                                            
  477    However, while this specification is not the place to try to address    
  478    these issues with local-parts, doing so is also not required to         
  479    determine the outcome of this experiment.  If this experiment           
  480    succeeds, then further work on email addresses with non-ASCII local-    
  481    parts will be needed and, based on the findings from this experiment,   
  482    that would be better than doing nothing or starting this experiment     
  483    based on a speculative approach to what is a very complex topic.        
  484                                                                            
  485                                                                            
  486                                                                            
  487                                                                            
  488                                                                            
  489                                                                            
  490                                                                            
  491                                                                            
  492 Wouters                       Experimental                      [Page 9]   

  493 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  494                                                                            
  495                                                                            
  496 5.  Application Use of OPENPGPKEY                                          
  497                                                                            
  498    The OPENPGPKEY record allows an application or service to obtain an     
  499    OpenPGP public key and use it for verifying a digital signature or      
  500    encrypting a message to the public key.  The DNS answer MUST pass       
  501    DNSSEC validation; if DNSSEC validation reaches any state other than    
  502    "Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be     
  503    treated as a failure.                                                   
  504                                                                            
  505 5.1.  Obtaining an OpenPGP Key for a Specific Email Address                
  506                                                                            
  507    If no OpenPGP public keys are known for an email address, an            
  508    OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key   
  509    that corresponds to that email address.  This public key can then be    
  510    used to verify a received signed message or can be used to send out     
  511    an encrypted email message.  An application whose attempt fails to      
  512    retrieve a DNSSEC-verified OPENPGPKEY RR from the DNS should remember   
  513    that failure for some time to avoid sending out a DNS request for       
  514    each email message the application is sending out; such DNS requests    
  515    constitute a privacy leak.                                              
  516                                                                            
  517 5.2.  Confirming that an OpenPGP Key is Current                            
  518                                                                            
  519    Locally stored OpenPGP public keys are not automatically refreshed.     
  520    If the owner of that key creates a new OpenPGP public key, that owner   
  521    is unable to securely notify all users and applications that have its   
  522    old OpenPGP public key.  Applications and users can perform an          
  523    OPENPGPKEY lookup to confirm that the locally stored OpenPGP public     
  524    key is still the correct key to use.  If the locally stored OpenPGP     
  525    public key is different from the DNSSEC-validated OpenPGP public key    
  526    currently published in DNS, the confirmation MUST be treated as a       
  527    failure unless the locally stored OpenPGP key signed the newly          
  528    published OpenPGP public key found in DNS.  An application that can     
  529    interact with the user MAY ask the user for guidance; otherwise, the    
  530    application will have to apply local policy.  For privacy reasons, an   
  531    application MUST NOT attempt to look up an OpenPGP key from DNSSEC at   
  532    every use of that key.                                                  
  533                                                                            
  534 5.3.  Public Key UIDs and Query Names                                      
  535                                                                            
  536    An OpenPGP public key can be associated with multiple email addresses   
  537    by specifying multiple key UIDs.  The OpenPGP public key obtained       
  538    from an OPENPGPKEY RR can be used as long as the query and resulting    
  539    data form a proper email to the UID identity association.               
  540                                                                            
  541    CNAMEs (see [RFC2181]) and DNAMEs (see [RFC6672]) can be followed to    
  542    obtain an OPENPGPKEY RR, as long as the original recipient's email      
line-417 Daniel Kahn Gillmor(Technical Erratum #4796) [Verified]
based on outdated version
   6.  The domain name (the "right-hand side" of the email address,
       called the "domain" in [RFC5322]) is appended to the result of
       step 2 to complete the prepared domain name.

It should say:
   6.  The domain name (the "right-hand side" of the email address,
       called the "domain" in [RFC5322]) is appended to the result of
       step 25 to complete the prepared domain name.

Technically, it should be step 5, not step 2: after step 2, there is no _openpgpkey label in the composed domain name. step 5 adds the _openpgpkey label.
  543    address appears as one of the OpenPGP public key UIDs.  For example,    
  544                                                                            
  545                                                                            
  546                                                                            
  547 Wouters                       Experimental                     [Page 10]   

  548 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  549                                                                            
  550                                                                            
  551    if the OPENPGPKEY RR query for hugh@example.com                         
  552    (8d57[...]b7._openpgpkey.example.com) yields a CNAME to                 
  553    8d57[...]b7._openpgpkey.example.net, and an OPENPGPKEY RR for           
  554    8d57[...]b7._openpgpkey.example.net exists, then this OpenPGP public    
  555    key can be used, provided one of the key UIDs contains                  
  556    "hugh@example.com".  This public key cannot be used if it would only    
  557    contain the key UID "hugh@example.net".                                 
  558                                                                            
  559    If one of the OpenPGP key UIDs contains only a single wildcard as the   
  560    left-hand side of the email address, such as "*@example.com", the       
  561    OpenPGP public key may be used for any email address within that        
  562    domain.  Wildcards at other locations (e.g., "hugh@*.com") or regular   
  563    expressions in key UIDs are not allowed, and any OPENPGPKEY RR          
  564    containing these MUST be ignored.                                       
  565                                                                            
  566 6.  OpenPGP Key Size and DNS                                               
  567                                                                            
  568    Due to the expected size of the OPENPGPKEY record, applications         
  569    SHOULD use TCP -- not UDP -- to perform queries for the OPENPGPKEY      
  570    resource record.                                                        
  571                                                                            
  572    Although the reliability of the transport of large DNS resource         
  573    records has improved in the last years, it is still recommended to      
  574    keep the DNS records as small as possible without sacrificing the       
  575    security properties of the public key.  The algorithm type and key      
  576    size of OpenPGP keys should not be modified to accommodate this         
  577    section.                                                                
  578                                                                            
  579    OpenPGP supports various attributes that do not contribute to the       
  580    security of a key, such as an embedded image file.  It is recommended   
  581    that these properties not be exported to OpenPGP public keyrings that   
  582    are used to create OPENPGPKEY resource records.  Some OpenPGP           
  583    software (for example, GnuPG) supports a "minimal key export" that is   
  584    well suited to use as OPENPGPKEY RDATA.  See Appendix A.                
  585                                                                            
  586 7.  Security Considerations                                                
  587                                                                            
  588    DNSSEC is not an alternative for the "web of trust" or for manual       
  589    fingerprint verification by users.  DANE for OpenPGP, as specified in   
  590    this document, is a solution aimed to ease obtaining someone's public   
  591    key.  Without manual verification of the OpenPGP key obtained via       
  592    DANE, this retrieved key should only be used for encryption if the      
  593    only other alternative is sending the message in plaintext.  While      
  594    this thwarts all passive attacks that simply capture and log all        
  595    plaintext email content, it is not a security measure against active    
  596    attacks.  A user who publishes an OPENPGPKEY record in DNS still        
  597                                                                            
  598                                                                            
  599                                                                            
  600                                                                            
  601                                                                            
  602 Wouters                       Experimental                     [Page 11]   

  603 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  604                                                                            
  605                                                                            
  606    expects senders to perform their due diligence by additional (non-      
  607    DNSSEC) verification of their public key via other out-of-band          
  608    methods before sending any confidential or sensitive information.       
  609                                                                            
  610    In other words, the OPENPGPKEY record MUST NOT be used to send          
  611    sensitive information without additional verification or confirmation   
  612    that the OpenPGP key actually belongs to the target recipient.          
  613                                                                            
  614    DNSSEC does not protect the queries from Pervasive Monitoring as        
  615    defined in [RFC7258].  Since DNS queries are currently mostly           
  616    unencrypted, a query to look up a target OPENPGPKEY record could        
  617    reveal that a user using the (monitored) recursive DNS server is        
  618    attempting to send encrypted email to a target.  This information is    
  619    normally protected by the MUAs and MTAs by using Transport Layer        
  620    Security (TLS) encryption using STARTTLS.  The DNS itself can           
  621    mitigate some privacy concerns, but the user needs to select a          
  622    trusted DNS server that supports these privacy-enhancing features.      
  623    Recursive DNS servers can support DNS Query Name Minimalisation         
  624    [RFC7816], which limits leaking the QNAME to only the recursive DNS     
  625    server and the nameservers of the actual zone being queried for.        
  626    Recursive DNS servers can also support TLS [RFC7858] to ensure that     
  627    the path between the end user and the recursive DNS server is           
  628    encrypted.                                                              
  629                                                                            
  630    Various components could be responsible for encrypting an email         
  631    message to a target recipient.  It could be done by the sender's MUA    
  632    or a MUA plug-in or the sender's MTA.  Each of these have their own     
  633    characteristics.  A MUA can ask the user to make a decision before      
  634    continuing.  The MUA can either accept or refuse a message.  The MTA    
  635    must deliver the message as-is, or encrypt the message before           
  636    delivering.  Each of these components should attempt to encrypt an      
  637    unencrypted outgoing message whenever possible.                         
  638                                                                            
  639    In theory, two different local-parts could hash to the same value.      
  640    This document assumes that such a hash collision has a negligible       
  641    chance of happening.                                                    
  642                                                                            
  643    Organizations that are required to be able to read everyone's           
  644    encrypted email should publish the escrow key as the OPENPGPKEY         
  645    record.  Mail servers of such organizations MAY optionally re-encrypt   
  646    the message to the individual's OpenPGP key.                            
  647                                                                            
  648 7.1.  MTA Behavior                                                         
  649                                                                            
  650    An MTA could be operating in a stand-alone mode, without access to      
  651    the sender's OpenPGP public keyring, or in a way where it can access    
  652    the user's OpenPGP public keyring.  Regardless, the MTA MUST NOT        
  653    modify the user's OpenPGP keyring.                                      
  654                                                                            
  655                                                                            
  656                                                                            
  657 Wouters                       Experimental                     [Page 12]   

  658 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  659                                                                            
  660                                                                            
  661    An MTA sending an email MUST NOT add the public key obtained from an    
  662    OPENPGPKEY resource record to a permanent public keyring for future     
  663    use beyond the TTL.                                                     
  664                                                                            
  665    If the obtained public key is revoked, the MTA MUST NOT use the key     
  666    for encryption, even if that would result in sending the message in     
  667    plaintext.                                                              
  668                                                                            
  669    If a message is already encrypted, the MTA SHOULD NOT re-encrypt the    
  670    message, even if different encryption schemes or different encryption   
  671    keys would be used.                                                     
  672                                                                            
  673    If the DNS request for an OPENPGPKEY record returned an Indeterminate   
  674    or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the    
  675    message and queue the plaintext message for encrypted delivery at a     
  676    later time.  If the problem persists, the email should be returned      
  677    via the regular bounce methods.                                         
  678                                                                            
  679    If multiple non-revoked OPENPGPKEY resource records are found, the      
  680    MTA SHOULD pick the most secure RR based on its local policy.           
  681                                                                            
  682 7.2.  MUA Behavior                                                         
  683                                                                            
  684    If the public key for a recipient obtained from the locally stored      
  685    sender's public keyring differs from the recipient's OPENPGPKEY RR,     
  686    the MUA SHOULD halt processing the message and interact with the user   
  687    to resolve the conflict before continuing to process the message.       
  688                                                                            
  689    If the public key for a recipient obtained from the locally stored      
  690    sender's public keyring contains contradicting properties for the       
  691    same key obtained from an OPENPGPKEY RR, the MUA SHOULD NOT accept      
  692    the message for delivery.                                               
  693                                                                            
  694    If multiple non-revoked OPENPGPKEY resource records are found, the      
  695    MUA SHOULD pick the most secure OpenPGP public key based on its local   
  696    policy.                                                                 
  697                                                                            
  698    The MUA MAY interact with the user to resolve any conflicts between     
  699    locally stored keyrings and OPENPGPKEY RRdata.                          
  700                                                                            
  701    A MUA that is encrypting a message SHOULD clearly indicate to the       
  702    user the difference between encrypting to a locally stored and          
  703    previously user-verified public key and encrypting to a public key      
  704    obtained via an OPENPGPKEY resource record that was not manually        
  705    verified by the user in the past.                                       
  706                                                                            
  707                                                                            
  708                                                                            
  709                                                                            
  710                                                                            
  711                                                                            
  712 Wouters                       Experimental                     [Page 13]   

  713 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  714                                                                            
  715                                                                            
  716 7.3.  Response Size                                                        
  717                                                                            
  718    To prevent amplification attacks, an Authoritative DNS server MAY       
  719    wish to prevent returning OPENPGPKEY records over UDP unless the        
  720    source IP address has been confirmed with [RFC7873].  Such servers      
  721    MUST NOT return REFUSED, but answer the query with an empty answer      
  722    section and the truncation flag set ("TC=1").                           
  723                                                                            
  724 7.4.  Email Address Information Leak                                       
  725                                                                            
  726    The hashing of the local-part in this document is not a security        
  727    feature.  Publishing OPENPGPKEY records will create a list of hashes    
  728    of valid email addresses, which could simplify obtaining a list of      
  729    valid email addresses for a particular domain.  It is desirable to      
  730    not ease the harvesting of email addresses where possible.              
  731                                                                            
  732    The domain name part of the email address is not used as part of the    
  733    hash so that hashes can be used in multiple zones deployed using        
  734    DNAME [RFC6672].  This does makes it slightly easier and cheaper to     
  735    brute-force the SHA2-256 hashes into common and short local-parts, as   
  736    single rainbow tables can be re-used across domains.  This can be       
  737    somewhat countered by using NextSECure version 3 (NSEC3).               
  738                                                                            
  739    DNS zones that are signed with DNSSEC using NSEC for denial of          
  740    existence are susceptible to zone walking, a mechanism that allows      
  741    someone to enumerate all the OPENPGPKEY hashes in a zone.  This can     
  742    be used in combination with previously hashed common or short local-    
  743    parts (in rainbow tables) to deduce valid email addresses.  DNSSEC-     
  744    signed zones using NSEC3 for denial of existence instead of NSEC are    
  745    significantly harder to brute-force after performing a zone walk.       
  746                                                                            
  747 7.5.  Storage of OPENPGPKEY Data                                           
  748                                                                            
  749    Users may have a local key store with OpenPGP public keys.  An          
  750    application supporting the use of OPENPGPKEY DNS records MUST NOT       
  751    modify the local key store without explicit confirmation of the user,   
  752    as the application is unaware of the user's personal policy for         
  753    adding, removing, or updating their local key store.  An application    
  754    MAY warn the user if an OPENPGPKEY record does not match the OpenPGP    
  755    public key in the local key store.                                      
  756                                                                            
  757    Applications that cannot interact with users, such as daemon            
  758    processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY     
  759    up to their DNS TTL value.  This avoids repeated DNS lookups that       
  760    third parties could monitor to determine when an email is being sent    
  761    to a particular user.                                                   
  762                                                                            
  763                                                                            
  764                                                                            
  765                                                                            
  766                                                                            
  767 Wouters                       Experimental                     [Page 14]   

  768 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  769                                                                            
  770                                                                            
  771 7.6.  Security of OpenPGP versus DNSSEC                                    
  772                                                                            
  773    Anyone who can obtain a DNSSEC private key of a domain name via         
  774    coercion, theft, or brute-force calculations, can replace any           
  775    OPENPGPKEY record in that zone and all of the delegated child zones.    
  776    Any future messages encrypted with the malicious OpenPGP key could      
  777    then be read.                                                           
  778                                                                            
  779    Therefore, an OpenPGP key obtained via a DNSSEC-validated OPENPGPKEY    
  780    record can only be trusted as much as the DNS domain can be trusted,    
  781    and is no substitute for in-person OpenPGP key verification or          
  782    additional OpenPGP verification via "web of trust" signatures present   
  783    on the OpenPGP in question.                                             
  784                                                                            
  785 8.  IANA Considerations                                                    
  786                                                                            
  787 8.1.  OPENPGPKEY RRtype                                                    
  788                                                                            
  789    This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has    
  790    been allocated by IANA from the "Resource Record (RR) TYPEs"            
  791    subregistry of the "Domain Name System (DNS) Parameters" registry.      
  792                                                                            
  793    The IANA template for OPENPGPKEY is listed in Appendix B.  It was       
  794    submitted to IANA for review on July 23, 2014 and approved on August    
  795    12, 2014.                                                               
  796                                                                            
  797 9.  References                                                             
  798                                                                            
  799 9.1.  Normative References                                                 
  800                                                                            
  801    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  802               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  803               November 1987, <http://www.rfc-editor.org/info/rfc1035>.     
  804                                                                            
  805    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  806               Requirement Levels", BCP 14, RFC 2119,                       
  807               DOI 10.17487/RFC2119, March 1997,                            
  808               <http://www.rfc-editor.org/info/rfc2119>.                    
  809                                                                            
  810    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
  811               Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,   
  812               <http://www.rfc-editor.org/info/rfc2181>.                    
  813                                                                            
  814    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  815               Rose, "DNS Security Introduction and Requirements",          
  816               RFC 4033, DOI 10.17487/RFC4033, March 2005,                  
  817               <http://www.rfc-editor.org/info/rfc4033>.                    
  818                                                                            
  819                                                                            
  820                                                                            
  821                                                                            
  822 Wouters                       Experimental                     [Page 15]   

  823 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  824                                                                            
  825                                                                            
  826    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  827               Rose, "Resource Records for the DNS Security Extensions",    
  828               RFC 4034, DOI 10.17487/RFC4034, March 2005,                  
  829               <http://www.rfc-editor.org/info/rfc4034>.                    
  830                                                                            
  831    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  832               Rose, "Protocol Modifications for the DNS Security           
  833               Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,     
  834               <http://www.rfc-editor.org/info/rfc4035>.                    
  835                                                                            
  836    [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data          
  837               Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,    
  838               <http://www.rfc-editor.org/info/rfc4648>.                    
  839                                                                            
  840    [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.    
  841               Thayer, "OpenPGP Message Format", RFC 4880,                  
  842               DOI 10.17487/RFC4880, November 2007,                         
  843               <http://www.rfc-editor.org/info/rfc4880>.                    
  844                                                                            
  845    [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic        
  846               Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January     
  847               2010, <http://www.rfc-editor.org/info/rfc5754>.              
  848                                                                            
  849 9.2.  Informative References                                               
  850                                                                            
  851    [HKP]      Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)",       
  852               Work in Progress, draft-shaw-openpgp-hkp-00, March 2003.     
  853                                                                            
  854    [MAILBOX]  Levine, J., "Encoding mailbox local-parts in the DNS",       
  855               Work in Progress, draft-levine-dns-mailbox-01, September     
  856               2015.                                                        
  857                                                                            
  858    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record     
  859               (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September       
  860               2003, <http://www.rfc-editor.org/info/rfc3597>.              
  861                                                                            
  862    [RFC4255]  Schlyter, J. and W. Griffin, "Using DNS to Securely          
  863               Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,      
  864               DOI 10.17487/RFC4255, January 2006,                          
  865               <http://www.rfc-editor.org/info/rfc4255>.                    
  866                                                                            
  867    [RFC4398]  Josefsson, S., "Storing Certificates in the Domain Name      
  868               System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,   
  869               <http://www.rfc-editor.org/info/rfc4398>.                    
  870                                                                            
  871    [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,      
  872               DOI 10.17487/RFC5321, October 2008,                          
  873               <http://www.rfc-editor.org/info/rfc5321>.                    
  874                                                                            
  875                                                                            
  876                                                                            
  877 Wouters                       Experimental                     [Page 16]   

  878 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  879                                                                            
  880                                                                            
  881    [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,       
  882               DOI 10.17487/RFC5322, October 2008,                          
  883               <http://www.rfc-editor.org/info/rfc5322>.                    
  884                                                                            
  885    [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for           
  886               Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,    
  887               February 2012, <http://www.rfc-editor.org/info/rfc6530>.     
  888                                                                            
  889    [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the        
  890               DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,             
  891               <http://www.rfc-editor.org/info/rfc6672>.                    
  892                                                                            
  893    [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication   
  894               of Named Entities (DANE) Transport Layer Security (TLS)      
  895               Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August      
  896               2012, <http://www.rfc-editor.org/info/rfc6698>.              
  897                                                                            
  898    [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an   
  899               Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May        
  900               2014, <http://www.rfc-editor.org/info/rfc7258>.              
  901                                                                            
  902    [RFC7816]  Bortzmeyer, S., "DNS Query Name Minimisation to Improve      
  903               Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,        
  904               <http://www.rfc-editor.org/info/rfc7816>.                    
  905                                                                            
  906    [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,     
  907               and P. Hoffman, "Specification for DNS over Transport        
  908               Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May   
  909               2016, <http://www.rfc-editor.org/info/rfc7858>.              
  910                                                                            
  911    [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)   
  912               Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,          
  913               <http://www.rfc-editor.org/info/rfc7873>.                    
  914                                                                            
  915    [SMIME]    Hoffman, P. and J. Schlyter, "Using Secure DNS to            
  916               Associate Certificates with Domain Names For S/MIME", Work   
  917               in Progress, draft-ietf-dane-smime-12, July 2016.            
  918                                                                            
  919    [Unicode90]                                                             
  920               The Unicode Consortium, "The Unicode Standard, Version       
  921               9.0.0", (Mountain View, CA: The Unicode Consortium,          
  922               2016. ISBN 978-1-936213-13-9),                               
  923               <http://www.unicode.org/versions/Unicode9.0.0/>.             
  924                                                                            
  925                                                                            
  926                                                                            
  927                                                                            
  928                                                                            
  929                                                                            
  930                                                                            
  931                                                                            
  932 Wouters                       Experimental                     [Page 17]   

  933 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  934                                                                            
  935                                                                            
  936 Appendix A.  Generating OPENPGPKEY Records                                 
  937                                                                            
  938    The commonly available GnuPG software can be used to generate a         
  939    minimum Transferable Public Key for the RRdata portion of an            
  940    OPENPGPKEY record:                                                      
  941                                                                            
  942    gpg --export --export-options export-minimal,no-export-attributes \     
  943        hugh@example.com | base64                                           
  944                                                                            
  945    The --armor or -a option of the gpg command should not be used, as it   
  946    adds additional markers around the armored key.                         
  947                                                                            
  948    When DNS software reading or signing of the zone file does not yet      
  949    support the OPENPGPKEY RRtype, the Generic Record Syntax of [RFC3597]   
  950    can be used to generate the RDATA.  One needs to calculate the number   
  951    of octets and the actual data in hexadecimal:                           
  952                                                                            
  953    gpg --export --export-options export-minimal,no-export-attributes \     
  954        hugh@example.com | wc -c                                            
  955    gpg --export --export-options export-minimal,no-export-attributes \     
  956        hugh@example.com | hexdump -e \                                     
  957           '"\t" /1 "%.2x"' -e '/32 "\n"'                                   
  958                                                                            
  959    These values can then be used to generate a generic record (line        
  960    break has been added for formatting):                                   
  961                                                                            
  962    <SHA2-256-trunc(hugh)>._openpgpkey.example.com. IN TYPE61 \# \          
  963        <numOctets> <keydata in hex>                                        
  964                                                                            
  965    The openpgpkey command in the hash-slinger software can be used to      
  966    generate complete OPENPGPKEY records                                    
  967                                                                            
  968    ~> openpgpkey --output rfc hugh@example.com                             
  969    c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]           
  970                                                                            
  971    ~> openpgpkey --output generic hugh@example.com                         
  972    c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...]       
  973                                                                            
  974                                                                            
  975                                                                            
  976                                                                            
  977                                                                            
  978                                                                            
  979                                                                            
  980                                                                            
  981                                                                            
  982                                                                            
  983                                                                            
  984                                                                            
  985                                                                            
  986                                                                            
  987 Wouters                       Experimental                     [Page 18]   

  988 RFC 7929                  DANE for OpenPGP Keys              August 2016   
  989                                                                            
  990                                                                            
  991 Appendix B.  OPENPGPKEY IANA Template                                      
  992                                                                            
  993    This is a copy of the original registration template submitted to       
  994    IANA; the text (including the references) has not been updated.         
  995                                                                            
  996   A. Submission Date: 23-07-2014                                           
  997                                                                            
  998   B.1 Submission Type: [x] New RRTYPE [ ] Modification to RRTYPE           
  999   B.2 Kind of RR: [x] Data RR [ ] Meta-RR                                  
 1000                                                                            
 1001   C. Contact Information for submitter (will be publicly posted):          
 1002      Name: Paul Wouters         Email Address: pwouters@redhat.com         
 1003      International telephone number: +1-647-896-3464                       
 1004      Other contact handles: paul@nohats.ca                                 
 1005                                                                            
 1006   D. Motivation for the new RRTYPE application.                            
 1007                                                                            
 1008      Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC         
 1009      protection to faciliate automatic encryption of emails in             
 1010      defense against pervasive monitoring.                                 
 1011                                                                            
 1012   E. Description of the proposed RR type.                                  
 1013                                                                            
 1014   http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2       
 1015                                                                            
 1016   F. What existing RRTYPE or RRTYPEs come closest to filling that need     
 1017      and why are they unsatisfactory?                                      
 1018                                                                            
 1019      The CERT RRtype is the closest match. It unfortunately depends on     
 1020      subtyping, and its use in general is no longer recommended. It        
 1021      also has no human usable presentation format. Some usage types of     
 1022      CERT require external URI's which complicates the security model.     
 1023      This was discussed in the dane working group.                         
 1024                                                                            
 1025   G. What mnemonic is requested for the new RRTYPE (optional)?             
 1026                                                                            
 1027      OPENPGPKEY                                                            
 1028                                                                            
 1029   H. Does the requested RRTYPE make use of any existing IANA registry      
 1030      or require the creation of a new IANA subregistry in DNS              
 1031      Parameters? If so, please indicate which registry is to be used       
 1032      or created. If a new subregistry is needed, specify the               
 1033      allocation policy for it and its initial contents. Also include       
 1034      what the modification procedures will be.                             
 1035                                                                            
 1036      The RDATA part uses the key format specified in RFC-4880, which       
 1037      itself use                                                            
 1038      https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtm   
 1039                                                                            
 1040                                                                            
 1041                                                                            
 1042 Wouters                       Experimental                     [Page 19]   

 1043 RFC 7929                  DANE for OpenPGP Keys              August 2016   
 1044                                                                            
 1045                                                                            
 1046      This RRcode just uses the formats specified in those registries for   
 1047      its RRdata part.                                                      
 1048                                                                            
 1049   I. Does the proposal require/expect any changes in DNS                   
 1050      servers/resolvers that prevent the new type from being processed      
 1051      as an unknown RRTYPE (see [RFC3597])?                                 
 1052                                                                            
 1053      No.                                                                   
 1054                                                                            
 1055   J. Comments:                                                             
 1056                                                                            
 1057      Currently, three software implementations of                          
 1058      draft-ietf-dane-openpgpkey are using a private number.                
 1059                                                                            
 1060 Acknowledgments                                                            
 1061                                                                            
 1062    This document is based on [RFC4255] and [SMIME] whose authors are       
 1063    Paul Hoffman, Jakob Schlyter, and W. Griffin.  Olafur Gudmundsson       
 1064    provided feedback and suggested various improvements.  Willem Toorop    
 1065    contributed the gpg and hexdump command options.  Daniel Kahn Gillmor   
 1066    provided the text describing the OpenPGP packet formats and filtering   
 1067    options.  Edwin Taylor contributed language improvements for various    
 1068    iterations of this document.  Text regarding email mappings was taken   
 1069    from [MAILBOX] whose author is John Levine.                             
 1070                                                                            
 1071 Author's Address                                                           
 1072                                                                            
 1073    Paul Wouters                                                            
 1074    Red Hat                                                                 
 1075                                                                            
 1076    Email: pwouters@redhat.com                                              
 1077                                                                            
 1078                                                                            
 1079                                                                            
 1080                                                                            
 1081                                                                            
 1082                                                                            
 1083                                                                            
 1084                                                                            
 1085                                                                            
 1086                                                                            
 1087                                                                            
 1088                                                                            
 1089                                                                            
 1090                                                                            
 1091                                                                            
 1092                                                                            
 1093                                                                            
 1094                                                                            
 1095                                                                            
 1096                                                                            
 1097 Wouters                       Experimental                     [Page 20]   
 1098                                                                            
line-543 James Manger(Editorial Erratum #4768) [Verified]
based on outdated version
For example, if the OPENPGPKEY RR query for hugh@example.com
(8d57[...]b7._openpgpkey.example.com) yields a CNAME to
8d57[...]b7._openpgpkey.example.net, and an OPENPGPKEY RR for
8d57[...]b7._openpgpkey.example.net exists,
It should say:
For example, if the OPENPGPKEY RR query for hugh@example.com
(8d57[...]b7c93f[...]d6._openpgpkey.example.com) yields a CNAME to
8d57[...]b7c93f[...]d6._openpgpkey.example.net, and an OPENPGPKEY RR for
8d57[...]b7c93f[...]d6._openpgpkey.example.net exists,

The example hash 8d57[...]b7 is wrong. It has been calculated with the wrong hash algorithm: SHA-224, instead of SHA-256. The correct hash is c93f[...]d6, which is shown in the example in section 3.