Subject: [pkix] Proposing CAA as PKIX Working Group Item

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 May 2011 12:35:19 -0400

All,

I presented CAA at the Prague SAAG. Since then a DNS RR has been assigned
and deployment is proceeding. Test vectors have been deployed and I should
be able to publish them (plus some reference code) shortly. An updated draft
is available at:

http://tools.ietf.org/html/draft-hallambaker-donotissue-04

The main substantive changes are (1) the change of the copyright to
modifications permitted and (2) inserting the new RR.

Three people have now implemented the draft independently and confirmed the
same test vectors.

The CAA protocol specification has two parts:

1) Issuer restrictions which may be used to specify which CAs are authorized
to issue certificates for a domain.

2) Relying party restrictions which may be used by relying applications.
Note that since certificates are valid for up to three years, whether an
application may rely on a certificate is not the same as whether a CA may
issue a new certificate.

There is also a bunch of 'social' and 'policy' infrastructure that has to be
layered on top of CAA, including the requirement that CAs verify CAA records
during issue as part of minimum issue requirements. This is not the place to
discuss that type of issue, that is something that really belongs in
CABForum. Equally, CABForum would prefer to avoid being a protocol standards
body.

The question now is what to do with respect to progressing CAA on standards
track. After discussion with the ADs, it appears that PKIX may be the best
place for the following reasons:

1) The purpose of CAA is entirely directed at how to issue and how to use
certificates. It is independent of any application layer (e.g. HTTP) or
transport layer (e.g. IPSEC, TLS) protocol.

2) CAA is designed to refine and improve the existing Internet PKI rather
than replace it with a new one.

3) CAA does not depend on DNSSEC. It is clearly better if a domain deploys
DNSSEC since that allows for better accountability. But DNSSEC deployment is
not a critical dependency.

4) The design tropes and architecture of CAA is designed with PKIX and PKIX
applications in mind. Thus ASN.1 OIDs are used as digest algorithm
identifiers and as object identifiers.

5) While the relying party restrictions bear some similarity to the
objectives of DANE, CAA is first and foremost an accountability control and
not an access control. As such CAA enables but does not does not depend on
deployment in applications.

One consequence of (5) is that CAA can be deployed without getting buy in
from the browser providers or other application providers. The only parties
that need to support CAA are Certification Authorities and they have a very
strong incentive to take any and all precautions to prevent miss-issue.

A second consequence of (5) is that the correct response to detecting a
certificate that is not compliant with the CAA record might be something
other than a client refusing to connect. If CAA is successful, fraudulent
issue events at sites with CAA records should be exceptionally rare and
those that do occur are more likely to be the result of mis-configuration
than an attack. Reporting non-compliant certs and using some other form of
revocation may provide a sufficient solution.

Both consequences mean that the protections of CAA extend beyond the
application clients that implement CAA. It is a refinement and improvement
of the existing deployed infrastructure, not a proposal to replace it with
something new.

A third consequence of (5) is that legacy infrastructure is going to be
accumulating round us as we attempt to work on the drafts. For this reason
we have been rather careful to provide a minimal set of initial functions
and a comprehensive extension mechanism (tag value pairs) rather than trying
to anticipate every possible use case and requirement.

At present CAA is specified as a global property of a DNS domain. It is not
currently possible to specify restrictions of the form 'Carol is authorized
to issue certificates for HTTPS for example.com but not for any other
protocol though there are ways in which the protocol could be extended to do
this should that use case be compelling.

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

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 17 May 2011 17:57:18 +1000

> The question now is what to do with respect to progressing CAA on standards track.

> After discussion with the ADs, it appears that PKIX may be the best place for the following reasons:

I support progressing CAA on the standards track, and doing so in PKIX. It looks like a useful and deployable scheme.

A couple of small comments:

1. It was confusing (to me) for "bit 0" of the "Flags" field to be the most significant bit. That is, a "Flags" value of 1 (as in many examples) means that "bit 7" is set ("Issuer use"), not bit 0 ("Critical"). I guess if this is DNS convention it should be kept, but it is the opposite to the convention in, say, ITU specs. The confusion is compounded as the flag names are introduced in 2.1 (eg "Critical"); followed by examples in 2.1.1 that use decimal values for the flags (eg CAA 1 policy ...); yet the bit numbers are not specified until 3.1. I guess I saw the first flag definition ("Critical") and the first example (with "1") and guessed they went together.

2. The "Critical" flag [2.1. The CAA RR type] should probably only apply to issuers if the "Issuer" flag is also set. Similarly, it should only apply to relying parties if the "Relying Party" flag is set. The text in 2.1 might imply this already if the "Issue" flag determines what is in the "Extended Issuer Authorization Set". The text in 3.1 "Syntax" however makes no such restriction: "A CA MUST NOT issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property type". 3.1 also seems to be missing the text about how the "Critical" flag affects relying parties. [It might be better if 3.1 doesn't duplicate 2.1 as much - just give bit numbers to flag names, leaving all description to 2.1].

3. 'flags' is an unsigned integer between 0 and 255, not 0 and 15 as stated in 3.1.1. "Canonical Presentation Format". Might be nicer to use hex, instead of decimal, since it is a bunch of bit fields (unless that is never done elsewhere in DNS text formats).

4. Has IANA created a CAA properties registry? In which case including the URI would be good. Though perhaps the text just says IANA has done this in anticipation.

Typo: extraneous "the" in 4. "Security considerations": "...increases the both the probability..."

--

James Manger

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 May 2011 07:48:38 -0700

I am confused by this request. Given that you have an RRtype assigned and already have implementations, it would be pretty destructive for this WG to accept the document and make any semantic or protocol changes. However, if we can't many any semantic or protocol changes (and I think both are warranted), why should the WG work on it at all? Wouldn't it be better to publish it as an RFC through the Independent Submissions Editor so that the protocol that has been deployed doesn't change?

These may be questions for the ADs, not for the WG.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 May 2011 10:53:59 -0400

On Tue, May 17, 2011 at 3:57 AM, Manger, James H <
[email-masked]> wrote:

> I support progressing CAA on the standards track, and doing so in PKIX. It
> looks like a useful and deployable scheme.
>
>
>
> 1. It was confusing (to me) for “bit 0” of the “Flags” field to be the most
> significant bit. That is, a “Flags” value of 1 (as in many examples) means
> that “bit 7” is set (“Issuer use”), not bit 0 (“Critical”). I guess if this
> is DNS convention it should be kept, but it is the opposite to the
> convention in, say, ITU specs.
>

It is the DNS convention and it confused the heck out of us while we were
writing the spec.

What I think I might do is to write them out as flags constants: 0x80 etc.

> The confusion is compounded as the flag names are introduced in 2.1 (eg
> “Critical”); followed by examples in 2.1.1 that use decimal values for the
> flags (eg CAA 1 policy …); yet the bit numbers are not specified until 3.1.
> I guess I saw the first flag definition (“Critical”) and the first example
> (with “1”) and guessed they went together.
>
>
>
> 2. The “Critical” flag [2.1. The CAA RR type] should probably only apply to
> issuers if the “Issuer” flag is also set. Similarly, it should only apply to
> relying parties if the “Relying Party” flag is set.
>

The idea of critical was to provide for an escape hole to allow an orderly
transition to a completely different scheme or possibly to allow for
exceptions to be specified 'Any EV issuer except Fred'.

What we might want to do though would be to separate out the critical for
relying and critical for issuer.

> The text in 2.1 might imply this already if the “Issue” flag determines
> what is in the “Extended Issuer Authorization Set”. The text in 3.1 “Syntax”
> however makes no such restriction: “A CA MUST NOT issue certificates for any
> Domain that contains a CAA critical property for an unknown or unsupported
> property type”. 3.1 also seems to be missing the text about how the
> “Critical” flag affects relying parties. [It might be better if 3.1 doesn’t
> duplicate 2.1 as much – just give bit numbers to flag names, leaving all
> description to 2.1].
>

Telling CAs what to do is relatively easy as there are few points to update
and they would have an immediate interest to update their software to track
changes.

Changing the relying side of things would be trickier as once that software
is released it is going to be legacy for a heck of a long time.

> 3. ‘flags’ is an unsigned integer between 0 and 255, not 0 and 15 as stated
> in 3.1.1. “Canonical Presentation Format”. Might be nicer to use hex,
> instead of decimal, since it is a bunch of bit fields (unless that is never
> done elsewhere in DNS text formats).
>

The 15 thing is an oversight (we extended the field to make DNS parsing
easier).

Again, the decimal thing is a DNS artifact :-(

> 4. Has IANA created a CAA properties registry? In which case including the
> URI would be good. Though perhaps the text just says IANA has done this in
> anticipation.
>

No IANA has assigned the RR but the registry would be created by the act of
publishing the ID as an RFC.

Typo: extraneous “the” in 4. “Security considerations”: “…increases the both
> the probability…”

Will fix in next version, thanks.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 May 2011 11:17:31 -0400

On Tue, May 17, 2011 at 10:48 AM, Paul Hoffman <[email-masked]>wrote:

> I am confused by this request. Given that you have an RRtype assigned and
> already have implementations, it would be pretty destructive for this WG to
> accept the document and make any semantic or protocol changes.

That depends on what the changes were and what motivated them.

This particular proposal crosses the boundary between PKIX and DNS. I don't
think it is particularly productive to have two separate groups working on a
proposal at the same time if it can be helped. Since assignment of the DNS
RR was blocking for deployment we worked on that aspect first.

I did however notify this WG that the draft had been proposed and was being
discussed in the DNS group.

There is still opportunity for this WG to make changes:

1) Propose changes to the description of the implementation.

2) Propose new property tags with different semantics.

3) Propose an entirely new syntax for the RR which would of course require a
new DNS RR assignment.

Which of these make sense depends entirely on what the reason behind the
change is and what the impact is. Change of type (1) is relatively cheap,
change of type (3) has much higher costs.

If the reason for a change is to support a new use case, fix a bug in the
spec or make the scheme more efficient then it may well make sense to
completely revise the spec and apply for a new RR. If on the other hand the
reason for the change is that someone wants to make a change I don't think
it is likely to get consensus.

I don't think it very likely that we are going to want to look at a complete
redesign. But I could imagine people have ideas for new property tags that
could be usefully added.

The DNS is the Internet infrastructure for making assertions about Internet
services associated with a domain name. If someone wants to make such an
assertion then it should appear in the DNS. If there is an assertion in the
DNS then it should relate directly or indirectly to an Internet service.

However, if we can't many any semantic or protocol changes (and I think both
> are warranted), why should the WG work on it at all? Wouldn't it be better
> to publish it as an RFC through the Independent Submissions Editor so that
> the protocol that has been deployed doesn't change?
>

Who suggested this particular course of action since CAA is clearly in PKIX
scope.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 May 2011 11:37:40 +0200

Phil,

I'm confused to. This draft to me seems to be an amendment of the DNS record
and not of the PKIX protocols.
If you want to define a way to carry X.509 data in a protocol, then PKIX is
usually not the place to do it, but the WG dealing with that protocol.

I'm not questioning your proposal or whether it should be standardized, just
why it ought to be dealt with by PKIX.

/Stefan

From:  Phillip Hallam-Baker <[email-masked]>
Date:  Wed, 18 May 2011 11:17:31 -0400
To:  Paul Hoffman <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] Proposing CAA as PKIX Working Group Item

> On Tue, May 17, 2011 at 10:48 AM, Paul Hoffman <[email-masked]> wrote:
> proposal at the same time if it can be helped. Since assignment of the DNS RR
> was blocking for deployment we worked on that aspect first.
> 
> If the reason for a change is to support a new use case, fix a bug in the spec
> or make the scheme more efficient then it may well make sense to completely
> revise the spec and apply for a new RR. If on the other hand the reason for
> the change is that someone wants to make a change I don't think it is likely
> to get consensus.
> 
> 
>> are warranted), why should the WG work on it at all? Wouldn't it be better to
>> publish it as an RFC through the Independent Submissions Editor so that the
>> protocol that has been deployed doesn't change?
>> 
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Tim Moses <[email-masked]>
Date: Wed, 25 May 2011 08:13:46 -0400

Phill. Entrust plans to incorporate a CAA check into its SSL certificate issuance procedures as soon as the remaining details are worked out. All the best. Tim.

On 2011-05-16, at 12:35 PM, "Phillip Hallam-Baker" <[email-masked]<mailto:[email-masked]>> wrote:

All,

I presented CAA at the Prague SAAG. Since then a DNS RR has been assigned and deployment is proceeding. Test vectors have been deployed and I should be able to publish them (plus some reference code) shortly. An updated draft is available at:

<http://tools.ietf.org/html/draft-hallambaker-donotissue-04>http://tools.ietf.org/html/draft-hallambaker-donotissue-04

The main substantive changes are (1) the change of the copyright to modifications permitted and (2) inserting the new RR.

Three people have now implemented the draft independently and confirmed the same test vectors.

1) Issuer restrictions which may be used to specify which CAs are authorized to issue certificates for a domain.

2) Relying party restrictions which may be used by relying applications. Note that since certificates are valid for up to three years, whether an application may rely on a certificate is not the same as whether a CA may issue a new certificate.

There is also a bunch of 'social' and 'policy' infrastructure that has to be layered on top of CAA, including the requirement that CAs verify CAA records during issue as part of minimum issue requirements. This is not the place to discuss that type of issue, that is something that really belongs in CABForum. Equally, CABForum would prefer to avoid being a protocol standards body.

The question now is what to do with respect to progressing CAA on standards track. After discussion with the ADs, it appears that PKIX may be the best place for the following reasons:

1) The purpose of CAA is entirely directed at how to issue and how to use certificates. It is independent of any application layer (e.g. HTTP) or transport layer (e.g. IPSEC, TLS) protocol.

2) CAA is designed to refine and improve the existing Internet PKI rather than replace it with a new one.

3) CAA does not depend on DNSSEC. It is clearly better if a domain deploys DNSSEC since that allows for better accountability. But DNSSEC deployment is not a critical dependency.

4) The design tropes and architecture of CAA is designed with PKIX and PKIX applications in mind. Thus ASN.1 OIDs are used as digest algorithm identifiers and as object identifiers.

5) While the relying party restrictions bear some similarity to the objectives of DANE, CAA is first and foremost an accountability control and not an access control. As such CAA enables but does not does not depend on deployment in applications.

One consequence of (5) is that CAA can be deployed without getting buy in from the browser providers or other application providers. The only parties that need to support CAA are Certification Authorities and they have a very strong incentive to take any and all precautions to prevent miss-issue.

A second consequence of (5) is that the correct response to detecting a certificate that is not compliant with the CAA record might be something other than a client refusing to connect. If CAA is successful, fraudulent issue events at sites with CAA records should be exceptionally rare and those that do occur are more likely to be the result of mis-configuration than an attack. Reporting non-compliant certs and using some other form of revocation may provide a sufficient solution.

Both consequences mean that the protections of CAA extend beyond the application clients that implement CAA. It is a refinement and improvement of the existing deployed infrastructure, not a proposal to replace it with something new.

A third consequence of (5) is that legacy infrastructure is going to be accumulating round us as we attempt to work on the drafts. For this reason we have been rather careful to provide a minimal set of initial functions and a comprehensive extension mechanism (tag value pairs) rather than trying to anticipate every possible use case and requirement.

At present CAA is specified as a global property of a DNS domain. It is not currently possible to specify restrictions of the form 'Carol is authorized to issue certificates for HTTPS for <http://example.com> example.com<http://example.com> but not for any other protocol though there are ways in which the protocol could be extended to do this should that use case be compelling.

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

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 May 2011 14:01:45 -0700

PKIX has in the past specified means of using DNS records for specifying
information that relates to management of PKIs.

The analogy I would use here is to SNMP. A MIB is part of the SNMP protocol
but the definition of the MIB itself is the job of the group that defines
the protocol that it describes.

Here CAA is a DNS record that provides information that is to be used by
Certificate Issuers. PKIX protocol is both the provider and the consumer of
this data. The DNS is merely the conduit.

The reason DNS is relevant here is that DNS has a unique relationship to the
interpretation of DNS names.

On Mon, May 23, 2011 at 2:37 AM, Stefan Santesson <[email-masked]>wrote:

> Phil,
>
> I'm confused to. This draft to me seems to be an amendment of the DNS
> record and not of the PKIX protocols.
> I'm not questioning your proposal or whether it should be standardized,
> just why it ought to be dealt with by PKIX.
>
> /Stefan
>
>
> 3) Propose an entirely new syntax for the RR which would of course require
> a new DNS RR assignment.
>
> I don't think it very likely that we are going to want to look at a
> complete redesign. But I could imagine people have ideas for new property
> tags that could be usefully added.
>
> However, if we can't many any semantic or protocol changes (and I think
>> both are warranted), why should the WG work on it at all? Wouldn't it be
>> better to publish it as an RFC through the Independent Submissions Editor so
>> that the protocol that has been deployed doesn't change?
>>

---

From: Alan Sill <[email-masked]>
Date: Wed, 25 May 2011 17:22:20 -0500

To me, based on the proposal and this description, CAA fits the  
definition of a profile rather than a base standard.  As such, it is  
still suitable as a work item, IMO, for this group, as profiles are  
still useful things.

Thanks,
Alan

On May 25, 2011, at 4:01 PM, Phillip Hallam-Baker wrote:

> PKIX has in the past specified means of using DNS records for  
> specifying information that relates to management of PKIs.
>
> The analogy I would use here is to SNMP. A MIB is part of the SNMP  
> protocol but the definition of the MIB itself is the job of the  
> group that defines the protocol that it describes.
>
> Here CAA is a DNS record that provides information that is to be  
> used by Certificate Issuers. PKIX protocol is both the provider and  
> the consumer of this data. The DNS is merely the conduit.
>
>
> The reason DNS is relevant here is that DNS has a unique  
> relationship to the interpretation of DNS names.
>
>
>
> On Mon, May 23, 2011 at 2:37 AM, Stefan Santesson <stefan@aaa- 
> sec.com> wrote:
> Phil,
>
> I'm confused to. This draft to me seems to be an amendment of the  
> DNS record and not of the PKIX protocols.
> If you want to define a way to carry X.509 data in a protocol, then  
> PKIX is usually not the place to do it, but the WG dealing with that  
> protocol.
>
> I'm not questioning your proposal or whether it should be  
> standardized, just why it ought to be dealt with by PKIX.
>
> /Stefan
>
>
> I am confused by this request. Given that you have an RRtype  
> assigned and already have implementations, it would be pretty  
> destructive for this WG to accept the document and make any semantic  
> or protocol changes.
>
> This particular proposal crosses the boundary between PKIX and DNS.  
> I don't think it is particularly productive to have two separate  
> groups working on a proposal at the same time if it can be helped.  
> Since assignment of the DNS RR was blocking for deployment we worked  
> on that aspect first.
>
> I did however notify this WG that the draft had been proposed and  
> was being discussed in the DNS group.
>
>
> 3) Propose an entirely new syntax for the RR which would of course  
> require a new DNS RR assignment.
>
> Which of these make sense depends entirely on what the reason behind  
> the change is and what the impact is. Change of type (1) is  
> relatively cheap, change of type (3) has much higher costs.
>
> If the reason for a change is to support a new use case, fix a bug  
> in the spec or make the scheme more efficient then it may well make  
> sense to completely revise the spec and apply for a new RR. If on  
> the other hand the reason for the change is that someone wants to  
> make a change I don't think it is likely to get consensus.
>
>
> complete redesign. But I could imagine people have ideas for new  
> property tags that could be usefully added.
>
> The DNS is the Internet infrastructure for making assertions about  
> Internet services associated with a domain name. If someone wants to  
> make such an assertion then it should appear in the DNS. If there is  
> an assertion in the DNS then it should relate directly or indirectly  
> to an Internet service.
>
>
> However, if we can't many any semantic or protocol changes (and I  
> think both are warranted), why should the WG work on it at all?  
> Wouldn't it be better to publish it as an RFC through the  
> Independent Submissions Editor so that the protocol that has been  
> deployed doesn't change?
>
> Who suggested this particular course of action since CAA is clearly  
> in PKIX scope.
>
>
>
>
> -- 
> _______________________________________________ pkix mailing list [email-masked] 
> <ATT00001..txt>

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Drane 162, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 May 2011 17:00:20 -0700

The CAA spec breaks down into two parts

1) Syntax for how to express the tag-value pair lists in the form of a DNS
record.

2) Interpretation of statements expressed in syntax above in the context of
certificate issue.

Part 1 of the spec is the only part that is relevant to DNSEXT and that work
is now complete. The RR syntax cannot now be changed for the CAA record. the
only way to make a change is by applying for a new RR.

Part 1 is also fairly straightforward. If tag value pairs can't solve a
problem then it is probably not a problem that can be solved at the DNS
level :-)

The area where work is required is in part 2. In particular questions such
as wether the description really tells issuers what they need to know in an
unambiguous format.

Another question that could come up is that people might say that they need
to be able to specify issue authorization on a per-protocol granularity (or
they may not).

On Wed, May 25, 2011 at 3:22 PM, Alan Sill <[email-masked]> wrote:

> To me, based on the proposal and this description, CAA fits the definition
> of a profile rather than a base standard.  As such, it is still suitable as
> a work item, IMO, for this group, as profiles are still useful things.
>
> Thanks,
> Alan
>
>
>> protocol but the definition of the MIB itself is the job of the group that
>> defines the protocol that it describes.
>>
>> The reason DNS is relevant here is that DNS has a unique relationship to
>> the interpretation of DNS names.
>>
>>
>>
>> If you want to define a way to carry X.509 data in a protocol, then PKIX
>> is usually not the place to do it, but the WG dealing with that protocol.
>>
>> This particular proposal crosses the boundary between PKIX and DNS. I
>> don't think it is particularly productive to have two separate groups
>> working on a proposal at the same time if it can be helped. Since assignment
>> of the DNS RR was blocking for deployment we worked on that aspect first.
>>
>> I did however notify this WG that the draft had been proposed and was
>> being discussed in the DNS group.
>>
>>
>> Internet services associated with a domain name. If someone wants to make
>> such an assertion then it should appear in the DNS. If there is an assertion
>> in the DNS then it should relate directly or indirectly to an Internet
>> service.
>>
>>
>> Who suggested this particular course of action since CAA is clearly in
>> PKIX scope.
>>
>>
>>
>>
>> --

---

From: koichi sugimoto <[email-masked]>
Date: Thu, 26 May 2011 12:20:28 +0900

I'm afraid that CAA as well as DANE are bad influence on the PKI.
The reason are:

1) Both drafts control certificate path validation, define trust
anchor, policy control, etc..
   Therefore, relying party must consider about 2 path validations,
one is pkix path validation
   and the other is CAA or DANE based path validation. Why cannot we
adopt only pkix based path validation?
   IMHO, pkix based path validation is carefully considerd among
PKIX-WG, so that, preventing the result of
   pkix based path validation by CAA or DANE based one seems to be
very dengerous.
   Recently, I happend to attend one of the DNSSEC meeting. In the
meeting, I'm very surprised at
   most of all the attendees are unfamiliar with PKI.
   Certificates chained up to public root are issued through vetting
from various security point of view.
   It's a very big problem if such kind of certificates are rejected
by some DNS with poor knowledged
   operators, I think.
   From this point, PKIX-WG is required to reconsider about CAA and DANE?

2) If DNS prohibits the issuarance of the certificate to some domain
except for pre-defined certification
   aurhorities, it seems to inhibit fee competition in the certification area.
   Further, if some mismatch between DNS registration (TLSA or CAA
record) and certificate issued to a web
   server occurred, it causes confusion in SSL area.

How should we cope with above?

Sorry for my poor english.

Regards,
Koichi Sugimoto.

2011/5/19 Phillip Hallam-Baker <[email-masked]>:
> [email-masked]

---

From: [email-masked]
Date: Thu, 26 May 2011 08:44:12 +0200

Hi Phill, the same is planning Izenpe to do.

Iñigo Barreira
Responsable del Área técnica
[email-masked]

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: [email-masked] [mailto:[email-masked]] En nombre de Tim Moses
Enviado el: miércoles, 25 de mayo de 2011 14:14
Para: Phillip Hallam-Baker
CC: [email-masked]
Asunto: Re: [pkix] Proposing CAA as PKIX Working Group Item

On 2011-05-16, at 12:35 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

	All,

	 

	 

	 

	 

	At present CAA is specified as a global property of a DNS domain. It is not currently possible to specify restrictions of the form 'Carol is authorized to issue certificates for HTTPS for example.com but not for any other protocol though there are ways in which the protocol could be extended to do this should that use case be compelling.

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 May 2011 17:56:13 +0200 (MEST)

> I'm afraid that CAA as well as DANE are bad influence on the PKI.

CAA does not have any influence, because it aimes at issuance policy
for commercial CAs only.

DANE does not have a bad influence, it offers cheaper or more easily
available alternatives to certificate path validation under a huge
set of independent omnipotent commercial CAs shipping preconfigured
as trust anchors with most TLS-capable (client) software.

>     anchor, policy control, etc..

CAA only affects CA issuing policy _at_the_time_of_issuing_.
A DNS admin that drops or replaces his CAA record does not
invalidate any existing server certificate by that DNS change.

Only DANE is targetting certificate path validation.

> 
> 2) If DNS prohibits the issurance of the certificate to some domain
>    except for pre-defined certification authorities, it seems to
>    inhibit fee competition in the certification area.

I'm failing to follow your line of thought.

DNS does not prohibt anything at all.

There may be DNS admins providing _guidance_ on certificate issuance
to commercial CAs for servers/hostnames in their domains. and these
DNS admins can publish this guidance with CAA DNS records.  The DNS
admins can change these CAA records whenever they see fit, it is
not supposed to affect the validity of the existing server certificates
and not be relevant to certificate path validation for any RP.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 May 2011 09:16:04 -0700

> and not be relevant to certificate path validation for any RP.

Martin is correct on all counts here except one minor one: the current draft is not limited to "commercial" CAs.

--Paul Hoffman

---

From: koichi sugimoto <[email-masked]>
Date: Fri, 27 May 2011 11:30:59 +0900

Hello Sirs,

> invalidate any existing server certificate by that DNS change.
If the 2nd column of CA RR record has bit-6 (relying application use)
and 3rd column of CAA RR record is "path",
then, the relying application may reject the issued certificate and therefore,
this produces the same result as invalid of path validation?

> and not be relevant to certificate path validation for any RP.

Suppose that an owner of a web server wants to get a certificate and
the domain is
authorized only to some CA domain A.
Then, the owner of the web server is likely to get the certificate
that belongs to the CA domain A,
because the owner of the web server requires additional steps to get
the certificate that belongs to
the CA domain B, where A is not equal to B.
I'm afraid that it produces unfair competition.

Regards,
Koichi Sugimoto.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 May 2011 00:12:55 -0400

> CAA does not have any influence, because it aimes at issuance policy

This is not the case and I suggest that you read the specification.

CAA is not just aimed at commercial CAs and it is not limited to issuance.

There are substantial differences between what CAA provides and what DANE is
considering. DANE is considering only one aspect of the key distribution
problem. CAA can use DNSSEC but does not require DNSSEC. DANE is absolutely
predicated on DNSSEC deployment.

> and not be relevant to certificate path validation for any RP.

If the domain name holder is saying 'do not issue a certificate for this
domain', why would any CA imagine that they should be doing that without
further process?

Let us imagine that there is in fact a problem where the domain registrar is
totallyevildns.com and they have published a CAA record for all their
domains specifying that only their in-house CA can issue.

When the first domain name holder attempts to issue a certificate from a
different CA that CA is going to generate an exception and place the
certificate issue process on hold while it is sorted out - just as for any
other exception. So then they are going to quickly discover what
totallyevildns.com has done and the likely outcome there is huge bad
publicity for the registrar and at least one lost customer.

A smart CA is going to have a backup plan involving transfer of the DNS
domain to a different registry worked out. But I rather doubt that it will
prove necessary.

If you have a DNS registrar or DNS outsourcer that is sticking unauthorized
junk in your zone you have a major security problem already.
-- 
Website: http://hallambaker.com/