[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 draft-ietf-pkix-caa

Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Experimental                               R. Stradling
Expires: April 21, 2011                                  Comodo CA, Ltd.
                                                        October 18, 2010


    DNS Certification Authority Authorization (CAA) Resource Record
                    draft-hallambaker-donotissue-00

Abstract

   The Certification Authority Authorization (CAA) DNS Resource Record
   allows a DNS domain name holder to specify the certificate signing
   certificate(s) authorized to issue certificates for that domain.  CAA
   resource records allow a public Certification Authority to implement
   additional controls to reduce the risk of unintended certificate mis-
   issue.  In additon, the CAA mechanism may be extended in future
   revisions to allow for use client enforcement of issuing
   restrictions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Hallam-Baker & Stradling  Expires April 21, 2011                [Page 1]


Internet-Draft    Certification Authority Authorization     October 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  The CAA RR type  . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Certification Authority Processing . . . . . . . . . . . .  4
       2.2.1.  Corresponding Domain Name  . . . . . . . . . . . . . .  5
       2.2.2.  Archive  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Application Processing . . . . . . . . . . . . . . . . . .  5
   3.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  dauth Property value . . . . . . . . . . . . . . . . .  7
         3.1.1.1.  Object Digest Identifier Calculation . . . . . . .  7
       3.1.2.  pauth Property value . . . . . . . . . . . . . . . . .  8
       3.1.3.  app Property value . . . . . . . . . . . . . . . . . .  8
     3.2.  Use of DNS Security  . . . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     4.1.  Mis-Issue by Authorized Certification Authority  . . . . .  8
     4.2.  Suppression or spoofing of CAA records . . . . . . . . . .  9
       4.2.1.  Applications . . . . . . . . . . . . . . . . . . . . .  9
       4.2.2.  Certification Authorities  . . . . . . . . . . . . . .  9
     4.3.  Denial of Service  . . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Registration of the CAA Resource Record Type . . . . . . .  9
     5.2.  Certification Authority Authorization Properties . . . . . 10
     5.3.  Certification Authority Authorization Application
           Properties . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Non Normative References . . . . . . . . . . . . . . . . . 11
   Appendix A.  ASN.1 Values (Non-Normative)  . . . . . . . . . . . . 11
     A.1.  Object Identifiers for Certificate Types . . . . . . . . . 11
     A.2.  Object Identifiers for Digest Algorithms . . . . . . . . . 11
     A.3.  DER Data Encoding Prefixes . . . . . . . . . . . . . . . . 12
       A.3.1.  Examples . . . . . . . . . . . . . . . . . . . . . . . 12
         A.3.1.1.  SHA2-256 Bit . . . . . . . . . . . . . . . . . . . 13
         A.3.1.2.  SHA2-512 Bit . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13



Hallam-Baker & Stradling  Expires April 21, 2011                [Page 2]


Internet-Draft    Certification Authority Authorization     October 2010


1.  Definitions

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Requirements

   The Certification Authority Authorization (CAA) DNS Resource Record
   allows a DNS domain name holder to specify the certificate signing
   certificate(s) authorized to issue certificates for that domain.  CAA
   resource records allow a public Certification Authority (CA) to
   implement additional controls to reduce the risk of unintended
   certificate mis-issue.

   Before issuing a certificate, a PKIX CA is required to validate the
   request according to the policies set out in its Certificate Policy
   Statement.  In the case of a public CA that validates certificate
   requests as a third party, the certificate will be typically issued
   under a public root certificate embedded in one or more relevant
   reliant applications.

   Criteria for inclusion of embedded root certificates in applications
   are outside the scope of this document but typically require the CA
   to publish a Certificate Practices Statement (CPS) that specifies how
   the requirements of the Certificate Policy (CP) are achieved and
   provide an annual audit statement of their performance against their
   CPS performed by an independent third party auditor.

   It is the intention of the authors to propose the CAA record defined
   in this document as the basis for CA validation requirements to be
   proposed in organizations that publish validation requirements such
   as the CA-Browser forum.

2.1.  The CAA RR type

   A CAA RR consists of a sequence of properties.  The following
   properties are defined:

   dauth  Identifies authorized issuers or end entity certificates by
      means of an Object Digest Identifier







Hallam-Baker & Stradling  Expires April 21, 2011                [Page 3]


Internet-Draft    Certification Authority Authorization     October 2010


      An issuer is identified by means of an Object Digest Identifier
      that corresponds to a certificate signing certificate under which
      the issuer is authorized to issue certificates.  An end entity
      certificate is identified by the digest of the certificate itself.

   pauth  Identifies authorized issuers or end entity certificates by
      means of a PKIX certificate policy OID.

      A pauth property states that an issuer is authorized to issue
      certificates for the corresponding domain that contain a policy
      OID within the specified polic arc, provided that this is
      consitent with both the CPS of the issuer and the requirements of
      the specified policy.

   app  Is used to inform clients that they MAY or MUST NOT use
      information in the CAA record to enforce CA issuing restrictions
      at the application level.

   Authorization to act as an issuer for a domain does not entail
   authorization to issue a certificate in response to a specific
   request.  An authorized issuer MUST comply with the requirements of
   its Certificate Policy and Certificate Practices Statement regardless
   of whether a CAA record is specified in a corresponding DNS domain or
   not.

   The authorizations specified in the dauth and pauth properties are
   additive.  If multiple authorization properties are specified it is
   sufficient for a single authorization property to match.  If no
   authorization property grants an issuer authorization, an issuer is
   not authorized and MUST NOT issue a certificate for that domain.

   For efficiency, certificates are identified in the dauth property by
   means of an Object Digest Identifier, a triple consisting of an ASN.1
   object identifier specifying the type of the referenced object, an
   ASN.1 object identifier specifying a digest algorithm and the digest
   value obtained by applying the specified digest algorithm to the
   referenced object.

2.2.  Certification Authority Processing

   Before issue of a certificate a compliant CA MUST check for
   publication of a relevant CAA Resource Record and if a record is
   published that the certificate requested is consistent with it.  If
   the certificate requested is not consistent with the CAA RR
   authorization, the CA MUST NOT issue the certificate.

   A certificate request is consistent with a relevant CAA Resource
   Record if and only if a valid certificate chain can be formed that:



Hallam-Baker & Stradling  Expires April 21, 2011                [Page 4]


Internet-Draft    Certification Authority Authorization     October 2010


      Includes the certificate to be issued as an end entity
      certificate.

      Contains at least one certificate specified as the object digest
      identifier value in an auth property.

   Note that while it MUST be possible to form a certificate validation
   path that contains at least one certificate that is so specified, it
   MAY also be possible to form valid certificate paths that are not.

   For example, a CA that has updated its root certificate to extend the
   expiry date is entitled to issue certificates for domains where the
   CAA record only specifies the older root certificate provided that
   the older root certificate has not actually expired and it is thus
   possible to form a valid certificate path.

2.2.1.  Corresponding Domain Name

   A CA MUST observe constraints published in a CAA record corresponding
   to any domain name specified as a subject name or subjectAltName in
   the requested certificate.

   A CA MUST observe constraints published in any CAA record that
   corresponds to a public DNS domain name issuing point for any domain
   name superior in the DNS hierarchy to any domain name specified as a
   subject name or subjectAltName in the requested certificate.

   For example, if a certificate is for an SSL server for the domain
   name www.example.com the CA MUST observe the constraints of any CAA
   record published at www.example.com and observe the constraints of
   any CAA record published at example.com.

2.2.2.  Archive

   A compliant CA SHOULD maintain an archive of the DNS transactions
   used to verify CAA eligibility.

   In particular a CA SHOULD ensure that where DNSSEC data is available
   that the corresponding signature and NSEC/NSEC3 records are preserved
   so as to enable later compliance audits.

2.3.  Application Processing

   While it is in theory possible to apply information contained in a
   CAA record to enforce certificate issue constraints at the
   application level, support for such processing is not a design goal
   for this version of the specification.




Hallam-Baker & Stradling  Expires April 21, 2011                [Page 5]


Internet-Draft    Certification Authority Authorization     October 2010


   The information provided in the CAA record MAY be used for
   application level enforcement of the CA authorization restrictions if
   the CAA RR property app=true is specified.

   An application MUST NOT use the information specified in a CAA RR if
   the app property is not specified or has the value false.  Use of app
   property values other than true or false is not defined.

   Application level enforcement of CAA restrictions faces the practical
   difficulty that different clients frequently use different trust
   chains to verify the same certificate chain.

   For example, a CA root embedded in 1995 might be replaced by a 'roll-
   over' certificate for the same subject and public key and a later
   expiry date in 2000, 2005 and 2010.

   While tracking such details is a requirement for a well run CA, a
   certificate subject rarely knows if or when a public CA root their
   certificate is issued under has been rolled over and has no means of
   predicting when it might be rolled over in the future.


3.  Mechanism

3.1.  Syntax

   A CAA RR contains a sequence of tag value pairs.  Each tag represents
   a property of the CAA record.  The value of a CAA property is that
   specified in the corresponding value field.

   A domain name MAY have multiple CAA RRs associated with it and each
   CAA RR MAY have multiple properties and a given property MAY be
   specified more than once.

   This version of the specification makes no distinction as to whether
   properties are expressed as one record or many, nor are the
   properties defined sensitive with respect to order.

   The CAA data field consists of a sequence of at least one property
   entry.  Each property entry consists of a sequence of:

   Tag Length  One octet containing an unsigned integer specifying the
      tag length in octets.  The tag length MUST be 15 octets or less.

   Tag  The property identifier, a sequence of lower case ascii
      characters





Hallam-Baker & Stradling  Expires April 21, 2011                [Page 6]


Internet-Draft    Certification Authority Authorization     October 2010


   Value Length  Two octets containing an unsigned integer in network
      byte order specifying the length of the value field in octets.

   Value  A sequence of octets representing the property value.
      Property values are encoded as binary values and MAY employ sub-
      formats.

   It is suggested that CAA records be represented in DNS configuration
   files (somehow).

   Implementations MUST allow CAA records to specify unknown tag values
   provided that they meet the tag length criteria.  In such cases
   implementations MUST allow tag values to be specified as Base64
   representations of binary strings and SHOULD allow tag values to be
   encoded as ASCII strings.

   Examples...

3.1.1.  dauth Property value

   Each dauth property specifies a single Object Digest Identifier
   value.  If dauth properties are to be declared for multiple
   certificates, a separate dauth property is required for each one.

3.1.1.1.  Object Digest Identifier Calculation

   An Object Digest is a binary structure with three components:

      An ASN.1 Object Identifier specifying the object type of the
      referenced object

      An ASN.1 Object Identifier specifying the digest algorithm

      An ASN.1 DER encoded data field containing the digest value of the
      referenced object processed using the specified digest algorithm.

   Examples...

   The Object Digest Identifier construction is designed to facilitate
   implementation in applications that already require ASN.1 handling
   mechanisms (i.e. most cryptographic applications) without causing an
   undue coding burden in cases where ASN.1 code is not already
   supported.  Appendix A provides all the necessary information to
   create a fully compliant Object Digest Identifier implementation.







Hallam-Baker & Stradling  Expires April 21, 2011                [Page 7]


Internet-Draft    Certification Authority Authorization     October 2010


3.1.2.  pauth Property value

   Each pauth property specifies a single ASN.1 OID value consisting of
   the ASN.1 type, length specifier and OID data.

   The pauth property applies to the specified policy OID and all policy
   OIDs that fall within the same OID arc.  If the OID arc 1.2.3 is
   specified, then the policy OIDs 1.2.3, 1.2.3.1, 1.2.3.1.2 etc. are
   all authorized.

3.1.3.  app Property value

   Tha app property is a case insensitive ASCII string.  Currently
   defined values are:

   true  Applications MAY use the pauth and dauth properties to enforce
      issuer authorization restrictions as certificate validity
      restrictions.

   false (default)  Applications MUST NOT use the data specified in the
      CAA record to enforce issuer authorization restrictions as
      certificate validity restrictions.

3.2.  Use of DNS Security

   Use of DNSSEC to authenticate CAA RRs is strongly recommended but not
   required.  A CA MUST observe a CAA RR that is returned whether it is
   signed using DNSSEC or not.

   Use of DNSSEC allows a CA to acquire and archive a non-repudiable
   proof that they were authorized to issue certificates for the domain


4.  Security Considerations

4.1.  Mis-Issue by Authorized Certification Authority

   Use of CAA records does not provide protection against mis-issue by
   an authorized Certification Authority.

   Domain name holders SHOULD ensure that the CAs they authorize to
   issue certificates for their domains employ appropriate controls to
   ensure that certificates are only issued to authorized parties within
   their organization.

   Such controls are most appropriately determined by the domain name
   holder and the authorized CA(s) directly and are thus out of scope of
   this document.



Hallam-Baker & Stradling  Expires April 21, 2011                [Page 8]


Internet-Draft    Certification Authority Authorization     October 2010


4.2.  Suppression or spoofing of CAA records

   Suppression of the CAA record or insertion of a bogus CAA record
   could enable an attacker to obtain a certificate from a CA that was
   not authorized to issue for that domain name.

4.2.1.  Applications

   Applications performing CAA checking SHOULD mitigate the risk of
   suppresion or spoofing of CAA records by means of DNSSEC validation
   where present.  In cases where DNSSEC validation is not available,
   CAA checking is of limited security value.

4.2.2.  Certification Authorities

   Since a certificate issued by a CA can be valid for several years,
   the consequences of a spoofing or suppression attack are much greater
   for Certification Authorities and so additional countermeasures are
   justified.

   A CA MUST mitigate this risk by employing DNSSEC verification
   whenever possible and rejecting certificate requests in any case
   where it is not possible to verify the non-existence or contents of a
   relevant CAA record.

   In cases where DNSSEC is not deployed in a corresponding domain, a CA
   SHOULD attempt to mitigate this risk by employing appropriate DNS
   security controls.  For example all portions of the DNS lookup
   process SHOULD be performed against the authoritative name server.
   Cached data MUST NOT be relied on but MAY be used to support
   additional anti-spoofing or anti-suppression controls.

4.3.  Denial of Service

   Introduction of a malformed or malicious CAA RR could in theory
   enable a Denial of Service attack.

   This specific threat is not considered to add significantly to the
   risk of running an insecure DNS service.


5.  IANA Considerations

5.1.  Registration of the CAA Resource Record Type

   IANA has assigned Resource Record Type TBD1 for the CAA Resource
   Record Type and added the line depicted below to the registry named
   Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395



Hallam-Baker & Stradling  Expires April 21, 2011                [Page 9]


Internet-Draft    Certification Authority Authorization     October 2010


   [RFC5395] and located at
   http://www.iana.org/assignments/dns-parameters.

 <             Value and meaning                              Reference
 -----------  ---------------------------------------------  ---------
 CAA          TBD1 Certification Authority Restriction         [RFCXXXX]

5.2.  Certification Authority Authorization Properties

   IANA has created the Certification Authority Authorization Properties
   registry with the following initial values:

 <
              Meaning                                          Reference
 -----------  -----------------------------------------------  ---------
 dauth        Object digest of authorized signing certificate  [RFCXXXX]
 pauth        Object Identifier of authorized policy           [RFCXXXX]
 app          Application Processing Flag                      [RFCXXXX]

   Addition of tag identifiers requires a public specification and
   expert review.

5.3.  Certification Authority Authorization Application Properties

   IANA has created the Certification Authority Authorization
   Application Properties registry with the following initial values:

 <
              Meaning                                          Reference
 -----------  -----------------------------------------------  ---------
 true         Applications MAY process pauth and dauth data    [RFCXXXX]
 false        Applications MUST NOT process CAA records        [RFCXXXX]

   Addition of tag identifiers requires a public specification and
   expert review.


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,



Hallam-Baker & Stradling  Expires April 21, 2011               [Page 10]


Internet-Draft    Certification Authority Authorization     October 2010


              June 2005.

6.2.  Non Normative References

   [NIST-ALGS]
              National Institute of Standards and Technology,
              "Cryptographic Algorithm Registration", March 2009.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.


Appendix A.  ASN.1 Values (Non-Normative)

   Although the Object Digest Identifier form employs ASN.1 DER encoding
   only a small subset of ASN.1 features are used and a full ASN.1 stack
   is not necessary.

   This appendix provides sufficient information to implement an Object
   Digest Identifier constructor or parser for the common

A.1.  Object Identifiers for Certificate Types

   OIDs have been defined in connection with the X.500 directory for
   user certificates, certification authority certificates, revocations
   of certification authority, and revocations of user certificates.
   The following table lists the OIDs, their BER encoding, and their
   type identifier and length-prefixed hex format for use in Object
   Digest Identifiers.



         == 06 03 55 04 24



         == 06 03 55 04 25

A.2.  Object Identifiers for Digest Algorithms

   OIDS have been assigned by NIST for the SHA2 digest algorithms
   [NIST-ALGS] [RFC4055] Use of the SHA1 digest algorithm is not
   recommended due to concerns for the security of the algorithm.

   The OID arc in each case is hashAlgs OBJECT IDENTIFIER ::= {joint-
   iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)



Hallam-Baker & Stradling  Expires April 21, 2011               [Page 11]


Internet-Draft    Certification Authority Authorization     October 2010


   nistAlgorithm(4) hashAlgs (2)}



         == 06 09 60 86 48 01 65 03 04 02 01



         == 06 09 60 86 48 01 65 03 04 02 02



         == 06 09 60 86 48 01 65 03 04 02 03



         == 06 09 60 86 48 01 65 03 04 02 04

A.3.  DER Data Encoding Prefixes

   The rules of ASN.1 encoding state that every data value is preceded
   by a data type identifier and a length identifier.  In the case of an
   Object Digest Identifier the data type identifier is always OCTET
   STRING (04) and the length for all currently defined digest
   algorithms will be less than 128 bytes (1024 bits) and thus use the
   single byte encoding form in which bit 7 is set to 0 and the lower 7
   bits specify the length.

   The length prefixes for commonly used digest lengths in hexadecimal
   notation are thus:

   160 bits  04 14

   224 bits  04 1C

   256 bits  04 20

   384 bits  04 30

   512 bits  04 40

A.3.1.  Examples

   The following examples demonstrate the formation of Object Digest
   Identifiers for the string 'test' using the ASN.1 OID value id-at-
   description = { joint-iso-ccitt(2) ds(5) at(4) 13 }





Hallam-Baker & Stradling  Expires April 21, 2011               [Page 12]


Internet-Draft    Certification Authority Authorization     October 2010


A.3.1.1.  SHA2-256 Bit

   The SHA2-256 digest value is 9F 86... 08

   The OID data in hexadecimal notation is:

      06 03 55 04 0D

      06 09 60 86 48 01 65 03 04 02 01

      04 20 9F 86 D0 81 88 4C 7D 65 9A 2F EA A0 C5 5A D0 15 A3 BF 4F 1B
      2B 0B 82 2C D1 5D 6C 15 B0 F0 0A 08

   The Base64 encoded digest value is:

   BgNVBA0GCWCGSAFlAwQCAQMgn4bQgYhMfWWaL+qgxVrQFaO
   /TxsrC4Is0V1sFbDwCgg=


A.3.1.2.  SHA2-512 Bit

   The SHA2-256 digest value is EE 26 ...  FF

   The OID data in hexadecimal notation is:

      06 03 55 04 0D

      06 09 60 86 48 01 65 03 04 02 03

      04 40 EE 26 B0 DD 4A F7 E7 49 AA 1A 8E E3 C1 0A E9 92 3F 61 89 80
      77 2E 47 3F 88 19 A5 D4 94 0E 0D B2 7A C1 85 F8 A0 E1 D5 F8 4F 88
      BC 88 7F D6 7B 14 37 32 C3 04 CC 5F A9 AD 8E 6F 57 F5 00 28 A8 FF

   The Base64 encoded digest value is:

   BgNVBA0GCWCGSAFlAwQCAwNA7iaw3Ur350mqGo7jwQrpkj9
   hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBM
   xfqa2Ob1f1ACio/w==


Authors' Addresses

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com





Hallam-Baker & Stradling  Expires April 21, 2011               [Page 13]


Internet-Draft    Certification Authority Authorization     October 2010


   Rob Stradling
   Comodo CA, Ltd.

   Email: rob.stradling@comodo.com















































Hallam-Baker & Stradling  Expires April 21, 2011               [Page 14]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/