Re: [dane] #29: Request new Reference Type - Public Key

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Richard L. Barnes
> Sent: Tuesday, August 23, 2011 7:40 PM
> To: John Gilmore
> Cc: dane issue tracker; Paul Hoffman; DANE WG
> Subject: Re: [dane] #29: Request new Reference Type - Public Key
> 
> Hi John,
> 
> Responses inline.
> 
> On Aug 23, 2011, at 6:57 PM, John Gilmore wrote:
> 
> >> In order to help focus the discussions (and provide guidance to our
> authors), I'm asking the WG to please indicate a preference for text based
> on:
> >> 1: The current wording.
> >> 2: The proposed split (based upon Jim's suggestion (
> >> http://www.ietf.org/mail-archive/web/dane/current/msg03223.html ))
> >> 3: Richard's "very different" proposal (outlined below).
> >
> > It seems to me that you're arguing about the contents of data fields
> > without clearly specifying what algorithms will be used to process
> > those data fields.  If we started with a clear description of the
> > algorithms, it would be a lot more obvious what data needs to exist to
> > support them.
> 
> I actually think we're more or less on the same page here.  The idea of my
> proposal was to describe the relying party actions that each association
type
> entails, and in particular, how it differs from how a client normally
processes
> a certificate according to RFC 5280.  I think a lot of the differences you
> mentions below are really just ambiguities that can and will be clarified
in
> eventual text for the document.
> 
> 
> > For example, Richard's revised proposal says things like "The service
> > certificate MUST pass standard PKIX validation (including chaining to
> > a trust anchor)".  That seems to beg the entire question, by leaving
> > "standard PKIX validation" undefined.  Two sentences later it says
> > that with a different Association Type value, "The service certificate
> > MUST pass standard PKIX validation" while implying that this means
> > WITHOUT chaining to a trust anchor.  So does standard PKIX validation
> > include ... what exactly?  Making sure that the internal length fields
> > are all valid?  Checking the values of the dozens of fields in a
> > certificate -- against what validators, exactly?  Checking for the
> > presence or absence of what fields, exactly?  All unspecified.  Not
> > very helpful for a committee trying to decide whether this proposal is
> > what the draft standard should say.
> 
> Sorry, it was understood that "standard PKIX validation" is the process
> described in RFC 5280:
> <http://tools.ietf.org/html/rfc5280#section-6>
> 
> 
> > Richard's formulation also seems to explicitly eliminate the ability
> > to specify the "service certificate" (or its public key) in the TLSA
> > record and yet not require ANY old-style trust anchors.  But that
> > depends on the subtleties of his Association Type 2: can the service
> > certificate itself be treated as a "trust anchor" in his "standard PKIX
> validation"
> > algorithm?  Or does a trust anchor need to be a separate key/cert from
> > the service certificate?  Answer: it doesn't say!
> 
> You cannot validate an X.509 certificate without reference to one or more
> trust anchors.  (I'm not sure what "old-style" means.)  In Association
Type 2,
> the certificate itself can indeed be used as a trust anchor material, in
which
> case the PKIX validation algorithm will just verify that it is a properly
formed
> self-signed certificate.
> 

Actually as a trust anchor there is no need for the certificate to be
self-signed.  The key is used without reference to any contents of the
certificate except for the public key information.
> 
> > <snip>
> >
> > Both Paul's and Richard's proposals, as well as draft 10, seem to gild
> > that lily by saying at what level of indirection the TLSA record "is
> > permitted to" authenticate a key or certificate.  While I'm sure we
> > can think up an infinite number of possible indirections that would
> > lead to that public key, each one that we add produces another set of
> > security challenges to be analyzed and another opportunity to screw it
> > up.  All the serious cryptographers threw up their hands in trying to
> > analyze IPSEC/IKE because it had so many options that they could never
> > complete a security analysis in less than a career.  Do we really want
> > to define another protocol like that?  Why don't we just specify:
> >
> >  *  If no TLSA record exists, do what the older RFCs say.
> >
> >  *  If the public key in the TLSA record is identical to the public
> >     key that the TLS session is based on (the "service certificate")
> >     then the protocol deems that public key trustworthy for the
> >     purposes of the TLS session.
> >
> >  *  If a TLSA record exists but its key does not match, break off the
> >     protocol and do not trust the server-supplied public key.
> >
> > and be done?
> 
> That's exactly what [Association Type 2, Reference Type = SPKI] does.
We're
> not done by doing that because there are other use cases:
> <http://tools.ietf.org/html/draft-ietf-dane-use-cases>
> 
> 
> > (I also note that the whole draft is written as if it's about
> > "certificates" and "certificate associations", though it also contains
> > wording that purports to make plain public keys useful.  There's small
> > print that giveth plain public keys, but the main flow of text seems
> > to taketh them away.)
> 
> This working group is about supporting TLS.  TLS does not support bare
public
> keys.  So the function of public keys in this context is to identify
certificates.
> 
> --Richard
> 
> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane