Subject: Re: [keyassure] Revised version of CAA

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 6 Dec 2010 15:58:54 -0600 (GMT-06:00)

Richard and Phillip,

  I agree with Rich's evaluation and one critical replacement
for 'anticompetitive' as well.  Nicely done Phillip and Ben,
ect.!

-----Original Message-----
>From: "Richard L. Barnes" <[email-masked]>
>Sent: Dec 6, 2010 3:46 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Revised version of CAA
>
>Just to be clear about scope/placement, I think this draft is pretty clearly within the domain of this working group.  I realize that the intended audience for these records is CAs, but they could just as easily be interpreted by clients and integrated into the TLS certificate acceptance process.  
>
>That said, on a quick read, this draft has some good ideas.  Certainly, the notion of a domain indicating what CA(s) MUST be in the chain seems useful.  Given that there are other useful constraints that are being discussed, however, I would prefer that this document be integrated in a more general framework for making statements about what certificates will be presented for a domain.  (I'm also a little leery of the use of words like "anticompetitive" in a specification; "abuse of the critical flag" might be a little more appropriate.)
>
>In any case, though, thanks to the authors for putting the draft forward.  Looking forward to doing a more thorough review and to more discussion,
>
>--Richard
>
>
>On Dec 6, 2010, at 12:09 PM, Phillip Hallam-Baker wrote:
>
>> All, a new version of CAA is available. This has been developed with
>> the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
>> proposal and is not intended to pre-empt or foreclose discussion here.
>> 
>> http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>> 
>> 
>> This version has significant changes from the last one. Some of which
>> may be relevant to KIDNS depending on what use cases are to be
>> considered. It should be noted however that the original use case for
>> CAA is outside the scope proposed for KIDNS, although the scheme
>> proposed is capable of use for purposes that are in scope.
>> 
>> In particular, the Object Digest Identifier is a general purpose
>> mechanism for providing a cryptographically authenticated reference to
>> an object instance by means of an ASN.1 structure as follows:
>> 
>>   DNSCAA DEFINITIONS ::=
>> 
>>   BEGIN
>> 
>>    ObjectDigestIdentifier ::= SEQUENCE {
>>      type             OBJECT IDENTIFIER,
>>      digestAlgorithm  OBJECT IDENTIFIER,
>>      digest           OCTET STRING
>>    }
>> 
>>   END
>> 
>> Thus the ODI of the certificate used in the example in Base64 format is:
>> 
>> MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP
>>   zKv6mI2D0yilif+7WhzmhMGLe/oBA==
>> 
>> This construction provides protection against a digest substitution
>> attack and a semantic substitution attack without a major increase in
>> the size of the digest value. While people may argue over the
>> relevance of such attacks to specific applications, it is the type of
>> issue that I much prefer to simply anticipate and dispose of in
>> advance.
>> 
>> The use of ASN.1 for this purpose is ideal since it is a very compact
>> format and widely used and supported in crypto libraries. While a full
>> ASN.1 implementation is considerably tedious and complex, the ODI only
>> uses a small subset that can be easily implemented without much
>> additional code. In effect the type and digestAlgorithm fields only
>> add a fixed constant string to the front of the items in question.
>> 
>> 
>> It would be rather nice if ODI digests could be emitted by
>> cryptographic applications as a general purpose 'fingerprint' that is
>> usable in multiple contexts. So the emitted digest can just be cut and
>> pasted from one place to another.
>> 
>> For example, it would be nice if we could have something like the
>> following in an HTML file:
>> 
>> <img href="http://blah.com/blah.jpg"
>> odi="digest:MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaPzKv6mI2D0yilif+7WhzmhMGLe/oBA=="/>
>> 
>> We have just created a transcluded reference to the object blah.jpg
>> which is authenticated by a secure digest value. The client could
>> reject the content if it does not match.
>> 
>> 
>> This approach is slightly less efficient space wise than the use of
>> DNSSEC code points for this purpose but has the advantage that there
>> is no need for additional registry maintenance effort when adding new
>> algorithms. There are very good reasons for wanting to keep the set of
>> digest algorithms used in DNSSEC small. There are less good reasons
>> for applying that to certificates. So I would not be surprised if the
>> DNSEXT group would end up preferring this approach on consideration.
>> 
>> -- 
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure
Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 8 Dec 2010 11:49:14 -0600 (GMT-06:00)

Carl and all,

  Perhaps there is some interest that ONLY CA's can determine
any or all policies on cert issuance is the only answer I can
think of at the moment.  There is some value in such a change
in policy and practice, but I doubt that it would be well
recieved.

-----Original Message-----
>From: Carl Wallace <[email-masked]>
>Sent: Dec 8, 2010 12:12 PM
>Why is it impractical for the CA to issue a certificate with the requested policy?  It should be no harder to get the policy right than it is to get the CA key right.  You could simply read the policies from the CA certificate and avoid requesting a policy that the CA can't issue.  
>
>> From: Phillip Hallam-Baker [mailto:[email-masked]]
>> Sent: Wednesday, December 08, 2010 1:07 PM
>> To: Carl Wallace
>> Cc: Ben Laurie; Nicholas Weaver; [email-masked]; PaulHoffman
>> I don't want to propagate reliance on lore, but I do want the exit strategy to
>> be as painless as possible.
>> 
>> In steady state this should be pretty easy to maintain. And I think that we will
>> naturally move to making the binding more specific over time. But having
>> gone through similar transitions, I do not want to push for something that
>> ends up being too strict.
>> 
>> My preference would to be to do RP enforcement on the basis of certs or
>> keys. Getting to the point where that is practical may require building
>> additional support infrastructure such as maintenance protocols. But that is
>> not something that should be in the critical path here.
>> 
>> 
>> On Wed, Dec 8, 2010 at 12:15 PM, Carl Wallace <[email-masked]>
>> wrote:
>> >> OK, how about the following:
>> >>
>> >> 1) If the policy property is marked for issue, an issuer is entitled
>> > to issue any
>> >> certificate that is consistent with that policy.
>> >
>> > Why is it important to allow the CA to assert a different policy than
>> > the client requested?
>> >
>> >> 2) If marked for client enforcement, the certificate must either
>> > contain the
>> >> specified OID or know it to be consistent with the specified OID by
>> > other
>> >> means.
>> >
>> > I do not understand what this buys the relying party.
>> >
>> >> My preference would be to use the path property for client
>> > enforcement.
>> >> But 'must use EV' is an important subset.
>> >
>> > If you don't want to enforce policy on the relying party, don't.  At
>> > present, there's an example for doing this.
>> >
>> >> If people really want to dig, it is not difficult to throw up corner
>> > cases on the
>> >> client enforcement side. My belief is that it is going to be
>> > relatively easy to
>> >> deal with these in practice because there is no particular value in a
>> > lot of the
>> >> complexity that has arisen, people just do things in different ways
>> > because
>> >> there was no particular reason not to.
>> >>
>> >> Deployment of CAA will cause issuers to look to rationalize their
>> > activities
>> >> which will in turn make the client enforcement side much easier to
>> > deal with.
>> >
>> > I think this implies an answer to my question above.  Maybe there's
>> > some way to address composite EV/OV/DV usage during this
>> > rationalization process.
>> >
>> >> Unfortunately, a great deal of the complexity here is lore rather
>> > something
>> >> that is written down in one place. As a CA, I am only really aware of
>> > the lore
>> >> that affects my products. And I am pretty sure that my competitors
>> > don't
>> >> want me to understand the issues that might arise from their lore.
>> >
>> > No need to propagate reliance on lore.  This doesn't seem particularly
>> > complicated.  There are a set of policy identifiers that indicate EV.
>> > An application must recognize these policies, use a trust anchor store
>> > with a set of trust anchors authorized for these policies and validate
>> > server certs to this trust anchor store to ensure it is valid under an
>> > EV policy.  This spec provides pre-issuance processing (and possibly
>> > some additional relying party checks), RFC 5280 and RFC 5937 define
>> > path processing from TA through server certificate.
>> >
>> >> So the traditional way we deal with this is to put a proposal on the
>> > table and
>> >> see who squawks. Then we adjust the proposal until everyone can live
>> > with
>> >> it.
>> >
>> > Fair enough.
>> >
>> 
>> 
>> 
>> --

Regards,
Jeffrey A. Williams