idnits 2.17.1 draft-ietf-pkix-caa-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2011) is 4571 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-THIS' is mentioned on line 594, but not defined == Unused Reference: 'RFC4055' is defined on line 618, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) ** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track R. Stradling 5 Expires: April 22, 2012 Comodo CA Ltd. 6 October 20, 2011 8 DNS Certification Authority Authorization (CAA) Resource Record 9 draft-ietf-pkix-caa-03 11 Abstract 13 The Certification Authority Authorization (CAA) DNS Resource Record 14 allows a DNS domain name holder to specify the certificate signing 15 certificate(s) authorized to issue certificates for that domain. CAA 16 resource records allow a public Certification Authority to implement 17 additional controls to reduce the risk of unintended certificate mis- 18 issue. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 22, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. The CAA RR type . . . . . . . . . . . . . . . . . . . . . 5 59 3. Certification Authority Processing . . . . . . . . . . . . . . 7 60 3.1. Canonical Domain Name . . . . . . . . . . . . . . . . . . 7 61 3.2. Use of DNS Security . . . . . . . . . . . . . . . . . . . 7 62 3.3. Archive . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.1.1. Canonical Presentation Format . . . . . . . . . . . . 9 66 4.2. CAA issue Property . . . . . . . . . . . . . . . . . . . . 10 67 4.3. CAA iodef Property . . . . . . . . . . . . . . . . . . . . 10 68 4.3.1. URL scheme mailto . . . . . . . . . . . . . . . . . . 11 69 4.3.2. URL scheme http . . . . . . . . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 5.1. Mis-Issue by Authorized Certification Authority . . . . . 12 72 5.2. Suppression or spoofing of CAA records . . . . . . . . . . 12 73 5.2.1. Applications . . . . . . . . . . . . . . . . . . . . . 12 74 5.2.2. Certification Authorities . . . . . . . . . . . . . . 12 75 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 13 76 5.4. Abuse of the Critical Flag . . . . . . . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Registration of the CAA Resource Record Type . . . . . . . 13 79 6.2. Certification Authority Authorization Properties . . . . . 13 80 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Definitions 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 1.2. Defined Terms 93 The following terms are used in this document: 95 Authorization Entry An authorization assertion that grants or denies 96 a specific set of permissions to a specific group of entities. 98 Canonical Domain Name A Domain Name that is not an alias. 100 Canonical Domain Name Value The value of a Canonical Domain Name. 101 The value resulting from applying alias transformations to a 102 Domain Name that is not canonical. 104 Certificate An X.509 Certificate, as specified in RFC 5280 105 [RFC5280]. 107 Certification Policy (CP) Specifies the criteria that a 108 Certification Authority undertakes to meet in its issue of 109 certificates. 111 Certification Practices Statement (CPS) Specifies the means by which 112 the criteria of the Certification Policy are met. In most cases 113 this will be the document against which the operations of the 114 Certification Authority are audited. 116 Certification Authority (CA) An entity that issues Certificates in 117 accordance with a specified Certification Policy. 119 Domain The set of resources associated with a DNS Domain Name. 121 Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and 122 revisions. 124 Domain Name System (DNS) The Internet naming system specified in RFC 125 1035 [RFC1035] and revisions. 127 DNS Security (DNSSEC) Extensions to the DNS that provide 128 authentication services as specified in RFC 4033 [RFC4033] and 129 revisions. 131 Extended Issuer Authorization Set The most specific Issuer 132 Authorization Set that is active for a domain. This is either the 133 Issuer Authorization Set for the domain itself, or if that is 134 empty, the Issuer Authorization Set for the corresponding Public 135 Delegation Point. 137 Issuer Authorization Set The set of Authorization Entries for a 138 domain name that are flagged for use by Issuers. Analogous to an 139 Access Control List but with no ordering specified. 141 Public Delegation Point A Domain Name that is obtained from a public 142 DNS registry. 144 Public Key Infrastructure X.509 (PKIX) Standards and specifications 145 issued by the IETF that apply the X.509 [X.509] certificate 146 standards specified by the ITU to Internet applications as 147 specified in RFC 5280 [RFC5280] and related documents. 149 Resource Record (RR) A set of attributes bound to a Domain Name. 151 Relying Party A party that makes use of an application whose 152 operation depends on use of a Certificate for making a security 153 decision. 155 Relying Application An application whose operation depends on use of 156 a Certificate for making a security decision. 158 2. Introduction 160 The Certification Authority Authorization (CAA) DNS Resource Record 161 allows a DNS domain name holder to specify the Certification 162 Authorities authorized to issue certificates for that domain. 163 Publication of CAA resource records allow a public Certification 164 Authority (CA) to implement additional controls to reduce the risk of 165 unintended certificate mis-issue. 167 Conformance with a published CAA record is a necessary but not 168 sufficient condition for issue of a certificate. Before issuing a 169 certificate, a PKIX CA is required to validate the request according 170 to the policies set out in its Certificate Policy Statement. In the 171 case of a public CA that validates certificate requests as a third 172 party, the certificate will be typically issued under a public root 173 certificate embedded in one or more relevant Relying Applications. 175 Criteria for inclusion of embedded root certificates in applications 176 are outside the scope of this document but typically require the CA 177 to publish a Certificate Practices Statement (CPS) that specifies how 178 the requirements of the Certificate Policy (CP) are achieved and 179 provide an annual audit statement of their performance against their 180 CPS performed by an independent third party auditor. 182 It is the intention of the authors to propose the CAA record defined 183 in this document as the basis for CA validation requirements to be 184 proposed in organizations that publish validation requirements. 186 CAA records only describe the current state of Certification 187 Authority certificate issue authority. Since a certificate is 188 typically valid for at least a year, it is possible that a 189 certificate that is not conformant with the CAA records currently 190 published was conformant with the CAA records published at the time 191 that it was issued. Thus Relying Applications MUST NOT use failure 192 to conform to currently published CAA records specifying issue 193 authorization as a certificate validity criteria. 195 2.1. The CAA RR type 197 A CAA RR publishes a CAA property entry that corresponds to the 198 specified domain name. Multiple property entries MAY be associated 199 with the same domain name by publishing multiple CAA RRs at that 200 domain name. Each property entry MAY be tagged with one or more of 201 the following flag values: 203 Critical If set, indicates that the corresponding property entry tag 204 MUST be understood if the semantics of the CAA record are to be 205 correctly understood by the specified audience. 207 Issuers MUST NOT issue certificates for a domain if the Extended 208 Issuer Authorization Set contains unknown property entry tags that 209 have both the Issuer and Critical bits set. 211 The following properties are defined: 213 issue [; ]* The policy property entry 214 declares an authorization entry granting authorization to issue 215 under the specified Certificate Policy to the holder of the 216 specified domain. 218 iodef Specifies a URL to which an issuer MAY report 219 certificate issue requests that are inconsistent with the issuer's 220 Certification Practices or Certification Policy using the IODEF 221 reporting format [RFC5070] 223 The following example informs CAs that certificates MUST NOT be 224 issued except by the holder of the domain name 'ca.example.net' or an 225 authorized agent thereof. Since the policy is published at the 226 Public Delegation Point, the policy applies to all subordinate 227 domains under example.com. 229 $ORIGIN example.com 230 . CAA 0 issue "ca.example.net" 232 If the domain name holder specifies one or more iodef properties, a 233 certificate issuer MAY report invalid certificate requests to that 234 address. In the following example the domain name holder specifies 235 that reports MAY be made by means of email with the IODEF data as an 236 attachment or a Web service or both: 238 $ORIGIN example.com 239 . CAA 0 issue "ca.example.net" 240 . CAA 0 iodef "mailto:security@example.com" 241 . CAA 0 iodef "http://iodef.example.com/" 243 A certificate issuer MAY specify additional parameters that allow 244 customers to specify additional parameters governing certificate 245 issue. For example, the Certification Policy under which the 246 certificate is to be issued or the authentication process to be used. 248 $ORIGIN example.com 249 . CAA 0 issue "ca.example.net; account=230123" 251 The syntax and semantics of such parameters is left to site policy 252 and is outside the scope of this document. 254 Future versions of this specification MAY use the critical flag to 255 introduce new semantics that MUST be understood for correct 256 processing of the record, preventing Certification Authorities that 257 do not recognize the record from issuing certificates. 259 In the following example, the property 'tbs' is flagged as critical. 260 The example.net CA is not authorized to issue under either policy 261 unless the processing rules for the 'tbs' property tag are 262 understood. 264 $ORIGIN example.com 265 . CAA 0 issue "ca.example.net; policy=ev" 266 . CAA 128 tbs "Unknown" 268 Note that the above restrictions only apply to issue of certificates. 269 Since the validity of an end entity certificate is typically a year 270 or more it is quite possible that the CAA records published at a 271 domain will change between the issue of the certificate and 272 verification by a relying party. 274 3. Certification Authority Processing 276 Before issue of a certificate, a compliant CA MUST check for 277 publication of a relevant CAA Resource Record(s) and if such 278 record(s) are published, that the certificate requested is consistent 279 with them. If the certificate requested is not consistent with the 280 relevant CAA RRs, the CA MUST NOT issue the certificate. 282 The Issuer Authorization Set for a domain name consists of the set of 283 all CAA Authorization Entries declared for the canonical form of the 284 specified domain. 286 The Extended Issuer Authorization Set for a domain name consists of 287 the Issuer Authorization Set for that domain name if it is non-empty. 288 Otherwise the Extended Issuer Authorization Set for a domain name 289 consists of the Issuer Authorization Set for the corresponding Public 290 Delegation Point for that domain name. 292 If the Extended Issuer Authorization Set for a domain name is not 293 empty, a Certification Authority MUST NOT issue a certificate unless 294 it conforms to at least one authorization entry in the Extended 295 Issuer Authorization Set. 297 3.1. Canonical Domain Name 299 The DNS defines the CNAME and DNAME mechanisms for specifying domain 300 name aliases. The canonical name of a DNS name is the name that 301 results from performing all DNS alias operations. 303 A Certification Authority MUST perform CNAME and DNAME processing as 304 defined in the DNS specifications 1035 [RFC1035] to resolve CAA 305 records. 307 3.2. Use of DNS Security 309 Use of DNSSEC to authenticate CAA RRs is strongly recommended but not 310 required. A CA MUST NOT issue certificates if doing so would 311 conflict with the corresponding extended issuer authorization set 312 whether the corresponding DNS records are signed or not. 314 Use of DNSSEC allows a CA to acquire and archive a non-repudiable 315 proof that they were authorized to issue certificates for the domain. 317 3.3. Archive 319 A compliant CA SHOULD maintain an archive of the DNS transactions 320 used to verify CAA eligibility. 322 In particular a CA SHOULD ensure that where DNSSEC data is available 323 that the corresponding signature and NSEC/NSEC3 records are preserved 324 so as to enable later compliance audits. 326 4. Mechanism 328 4.1. Syntax 330 A CAA RR contains a single property entry consisting of a tag value 331 pair. Each tag represents a property of the CAA record. The value 332 of a CAA property is that specified in the corresponding value field. 334 A domain name MAY have multiple CAA RRs associated with it and a 335 given property MAY be specified more than once. 337 The CAA data field contains one property entry. A property entry 338 consists of the following data fields: 340 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 341 | Flags | Tag Length = n | 342 +----------------+----------------+...+---------------+ 343 | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | 344 +----------------+----------------+...+---------------+ 345 +----------------+----------------+.....+---------------+ 346 | Data byte 0 | Data byte 1 |.....| Data byte m-1 | 347 +----------------+----------------+.....+---------------+ 349 Where n is the length specified in the tag length field and m is the 350 remaining octets in the data field (m = d - n - 2) where d is the 351 length of the data section. 353 The data fields are defined as follows: 355 Flags One octet containing the following fields: 357 Bit 0: Critical Flag If the value is set (1), the critical flag 358 is asserted and the property MUST be understood if the CAA 359 record is to be correctly processed by a certificate issuer. 361 A Certification Authority MUST NOT issue certificates for any 362 Domain that contains a CAA critical property for an unknown or 363 unsupported property type that has the issuer bit set. 365 Note that according to the conventions set out in RFC 1035 366 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 367 Significant. Thus the flags value 1 means that bit 7 is set while 368 a value of 128 means that bit 0 is set according to this 369 convention. 371 All other bit positions are reserved for future use. 373 To ensure compatibility with futuree extensions to CAA, DNS 374 records compliant with this version of the CAA specification MUST 375 clear (0) all reserved flags bits. Applications that interpret 376 CAA records MUST ignore the value of all reserved flag bits. 378 Tag Length A single octet containing an unsigned integer specifying 379 the tag length in octets. The tag length MUST be at least 1 and 380 SHOULD be no more than 15. 382 Tag The property identifier, a sequence of ASCII characters. 384 Tag values MAY contain ASCII characters a through z and the 385 numbers 0 through 9. Tag values MUST NOT contain any other 386 characters. Matching of tag values is case insensitive. 388 Value A sequence of octets representing the property value. 389 Property values are encoded as binary values and MAY employ sub- 390 formats. 392 The length of the value field is specified implicitly as the 393 remaining length of the enclosing Resource Record data field. 395 4.1.1. Canonical Presentation Format 397 The canonical presentation format of the CAA record is as follows: 399 CAA 401 Where: 403 flags Is an unsigned integer between 0 and 15. 405 tag Is a non-zero sequence of ASCII letter and numbers in lower 406 case. 408 data Is the ascii text Encoding of the value field 410 4.2. CAA issue Property 412 The issue property is used to request that certificate issuers 413 perform CAA issue restriction processing for the domain and to grant 414 authorization to specific certificate issuers. 416 The CAA issue property value has the following sub-syntax: 418 [domain-name] whitespace ';' issuer-parameters 420 A CAA record with an issue parameter tag that does not specify a 421 domain name is a request that certificate issuers perform CAA issue 422 restriction processing for the corresponding domain without granting 423 authorization to any certificate issuer. 425 This form of issue restriction would be appropriate for use with a 426 domain that the domain name owner does not intend to be used. 428 For example, the following CAA record set requests that no 429 certificates be issued for the domain 'nocerts.example.com' by any 430 certificate issuer. 432 nocerts.example.com CAA 0 issue ";" 434 A CAA record with an issue parameter tag that specifies a domain name 435 is a request that certificate issuers perform CAA issue restriction 436 processing for the corresponding domain and grants authorization to 437 the certificate issuer specified by the domain name. 439 For example, the following CAA record set requests that no 440 certificates be issued for the domain 'certs.example.com' by any 441 certificate issuer other than the example.net certificate issuer. 443 certs.example.com CAA 0 issue "example.net" 445 An issuer MAY choose to specify issuer-parameters that further 446 constrain the issue of certificates by that issuer. For example 447 specifying that certificates are to be subject to specific validation 448 polices, billed to certain accounts or issued off specific roots. 450 The syntax and semantics of issuer-parameters are determined by the 451 issuer alone. 453 4.3. CAA iodef Property 455 The iodef property specifies a means of reporting certificate issue 456 requests or cases of certificate issue for the corresponding domain 457 that violate the security policy of the issuer or the domain name 458 holder. 460 The iodef property takes a URL as its parameter. The URL scheme type 461 determines the method used for reporting: 463 mailto The IODEF incident report is reported as a MIME email 464 attachment to an SMTP email that is submitted to the mail address 465 specified. 467 http or https The IODEF report is submitted as a RID Web Service 468 request to the HTTP address specified. 470 4.3.1. URL scheme mailto 472 The email sent should contain the incident report presented in 473 natural language and an IODEF document as a MIME attachment 474 [RFC2045]. 476 [[Need to deal with language issues later]] 478 4.3.2. URL scheme http 480 (transport via RID) [RFC6046] 482 5. Security Considerations 484 CAA Records provide an accountability control. They are intended to 485 deter rather than prevent undesired behavior. 487 While a Certification Authority can choose to ignore published CAA 488 records, doing so increases the both the probability that they will 489 mis-issue a certificate and the consequences of doing so. Once it is 490 known that a CA observes CAA records, malicious registration requests 491 will disproportionately target the negligent CAs that do not, and so 492 the mis-issue rate amongst the negligent CAs will increase. Since 493 the CA could clearly have avoided the mis-issue by performing CAA 494 processing, the likelihood of sanctions against the negligent CA is 495 increased. Failure to observe CAA issue restrictions provides an 496 objective criteria for excluding issuers from embedded roots of 497 trust. 499 In contrast, a Certification Authority that processes CAA records 500 correctly can reasonably claim that any residual mis-issue event 501 could have been avoided had the Domain Name holder published 502 appropriate CAA records. 504 5.1. Mis-Issue by Authorized Certification Authority 506 Use of CAA records does not provide protection against mis-issue by 507 an authorized Certification Authority. 509 Domain name holders SHOULD ensure that the CAs they authorize to 510 issue certificates for their domains employ appropriate controls to 511 ensure that certificates are only issued to authorized parties within 512 their organization. 514 Such controls are most appropriately determined by the domain name 515 holder and the authorized CA(s) directly and are thus out of scope of 516 this document. 518 5.2. Suppression or spoofing of CAA records 520 Suppression of the CAA record or insertion of a bogus CAA record 521 could enable an attacker to obtain a certificate from a CA that was 522 not authorized to issue for that domain name. 524 5.2.1. Applications 526 Applications performing CAA checking SHOULD mitigate the risk of 527 suppresion or spoofing of CAA records by means of DNSSEC validation 528 where present. In cases where DNSSEC validation is not available, 529 CAA checking is of limited security value. 531 5.2.2. Certification Authorities 533 Since a certificate issued by a CA can be valid for several years, 534 the consequences of a spoofing or suppression attack are much greater 535 for Certification Authorities and so additional countermeasures are 536 justified. 538 A CA MUST mitigate this risk by employing DNSSEC verification 539 whenever possible and rejecting certificate requests in any case 540 where it is not possible to verify the non-existence or contents of a 541 relevant CAA record. 543 In cases where DNSSEC is not deployed in a corresponding domain, a CA 544 SHOULD attempt to mitigate this risk by employing appropriate DNS 545 security controls. For example all portions of the DNS lookup 546 process SHOULD be performed against the authoritative name server. 547 Cached data MUST NOT be relied on but MAY be used to support 548 additional anti-spoofing or anti-suppression controls. 550 5.3. Denial of Service 552 Introduction of a malformed or malicious CAA RR could in theory 553 enable a Denial of Service attack. 555 This specific threat is not considered to add significantly to the 556 risk of running an insecure DNS service. 558 5.4. Abuse of the Critical Flag 560 A Certification Authority could make use of the critical flag to 561 trick customers into publishing records which prevent competing 562 Certification Authorities from issuing certificates even though the 563 customer intends to authorize multiple providers. 565 In practice, such an attack would be of minimal effect since any 566 competent competitor that found itself unable to issue certificates 567 due to lack of support for a property marked critical is going to 568 investigate the cause and report the reason to the customer who was 569 deceived. It is thus unlikely that the attack would succeed and the 570 attempt might lay the perpetrator open to civil or criminal 571 sanctions. 573 6. IANA Considerations 575 6.1. Registration of the CAA Resource Record Type 577 IANA has assigned Resource Record Type 257 for the CAA Resource 578 Record Type and added the line depicted below to the registry named 579 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 580 [RFC5395] and located at 581 http://www.iana.org/assignments/dns-parameters. 583 Value and meaning Reference 584 ----------- --------------------------------------------- --------- 585 CAA 257 Certification Authority Restriction [RFC-THIS] 587 6.2. Certification Authority Authorization Properties 589 IANA has created the Certification Authority Authorization Properties 590 registry with the following initial values: 592 Meaning Reference 593 ----------- ----------------------------------------------- --------- 594 issue Authorization Entry by Domain [RFC-THIS] 595 auth Reserved 596 path Reserved 597 policy Reserved 599 Addition of tag identifiers requires a public specification and 600 expert review as set out in RFC5395 [RFC5395] 602 7. Normative References 604 [RFC1035] Mockapetris, P., "Domain names - implementation and 605 specification", STD 13, RFC 1035, November 1987. 607 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 608 Extensions (MIME) Part One: Format of Internet Message 609 Bodies", RFC 2045, November 1996. 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, March 1997. 614 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 615 Rose, "DNS Security Introduction and Requirements", 616 RFC 4033, March 2005. 618 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 619 Algorithms and Identifiers for RSA Cryptography for use in 620 the Internet X.509 Public Key Infrastructure Certificate 621 and Certificate Revocation List (CRL) Profile", RFC 4055, 622 June 2005. 624 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 625 Object Description Exchange Format", RFC 5070, 626 December 2007. 628 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 629 Housley, R., and W. Polk, "Internet X.509 Public Key 630 Infrastructure Certificate and Certificate Revocation List 631 (CRL) Profile", RFC 5280, May 2008. 633 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 634 Considerations", RFC 5395, November 2008. 636 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 637 Inter-network Defense (RID) Messages", RFC 6046, 638 November 2010. 640 [X.509] International Telecommunication Union, "ITU-T 641 Recommendation X.509 (11/2008): Information technology - 642 Open systems interconnection - The Directory: Public-key 643 and attribute certificate frameworks", ITU-T 644 Recommendation X.509, November 2008. 646 Authors' Addresses 648 Phillip Hallam-Baker 649 Comodo Group Inc. 651 Email: philliph@comodo.com 653 Rob Stradling 654 Comodo CA Ltd. 656 Email: rob.stradling@comodo.com