Subject: I-D Action: draft-ietf-pkix-caa-02.txt

From: [email-masked]
Date: Thu, 08 Sep 2011 10:04:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : DNS Certification Authority Authorization (CAA) Resource Record
	Author(s)       : Phillip Hallam-Baker
                          Rob Stradling
                          Ben Laurie
	Filename        : draft-ietf-pkix-caa-02.txt
	Pages           : 13
	Date            : 2011-09-08

   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-02.txt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Sep 2011 13:38:24 -0400

This rev is mostly removing the stuff the WG does not want in PKIX scope and
changing from policy OIDs and path digests to domain names.

I have marked the old issue properties plus the auth property Google uses in
Chrome as 'reserved' to stop them being re-assigned.

I have not fully speced out how to use domain names yet. Assume that the
draft says all the right things about I18N etc.

The question to consider is what attributes we might want to permit in the
data field beyond the domain name. I see the following as possible:

1) Nothing
2) Standard attributes defined by the spec
3) Non standard attributes defined by the issuer
4) A mixture of 2 and 3.

My preference is 2 with maybe leaving the door open to 4 later on.

The reason I might want to have this type of information is that it allows
the CA to support requests to restrict issue to particular policies,
particular EKUs, etc. etc. Some of those features might be something we
could eventually agree on a standard for, but quite a few are not.

Since everything in the CAA record apart from the domain name is essentially
a conversation between the customer and their chosen CA the simplest
approach is to leave this to the CA and their customer.

If conventions do emerge over time (e.g. policy=EV) that seem worth noting
then we can do a BIS version of CAA and include them.

In order to keep the door open to the latter, I would suggest that any
subfield encoding for the data field be the SMTP header format  [tag=value
(; tag=value)* ]

On Thu, Sep 8, 2011 at 1:04 PM, <[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Public-Key Infrastructure
> (X.509) Working Group of the IETF.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

-- 
Website: http://hallambaker.com/