Subject: [dane] Comments on Appendex B

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Aug 2011 17:23:52 -0700

1.  The text makes the assumption at all new reference types are going to be
hashes.  I do not agree that this is true statement.  Therefore the second
condition should be

Else if (R.referenceType is both known and a hash) AND (hash(R.referenceType
of C) == R.certAssoc) {

2.  The comment for R.certType == 2 is incorrect.  I believe it should be:

// a PKIX certificate that identifies a Trust Anchor

3.  Is there a reason that the hash checks were emitted from the R.certType
== 2 logic?  If not then this should be tagged as an invalid record and the
logic for handling this event is deferred until the end of the loop (i.e.
set a state variable and continue).  Specifically this text does not
distinguish between an unrecognized record type and an ill formed record
type in any way.  This is a current discussion topic.

4.  See comment #1 about the text for R.certType == 3 as well.

Jim

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 16 Aug 2011 21:12:26 +0200

> Else if (R.referenceType is both known and a hash) AND (hash(R.referenceType

I was under the assumption that the reference type is always the identity reference or a hash. What other types can you think of?

> // a PKIX certificate that identifies a Trust Anchor

section 2.1.1 says that cert type 2 is "A PKIX certification authority's certificate". We could of course change that, but it should be consistent.

	jakob

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 16 Aug 2011 13:14:28 -0700

> -----Original Message-----
> From: Jakob Schlyter [mailto:[email-masked]]
> Sent: Tuesday, August 16, 2011 12:12 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [dane] Comments on Appendex B
> 
> > 1.  The text makes the assumption at all new reference types are going
> > to be hashes.  I do not agree that this is true statement.  Therefore
> > the second condition should be
> >
> > Else if (R.referenceType is both known and a hash) AND
> > (hash(R.referenceType of C) == R.certAssoc) {
> 
> I was under the assumption that the reference type is always the identity
> reference or a hash. What other types can you think of?

Well - I have proposed that it could be a public key in a new tracker item.
That would be something that is neither identity or a hash.

> section 2.1.1 says that cert type 2 is "A PKIX certification authority's
> certificate". We could of course change that, but it should be consistent.

In my big review mail - I said that I wanted to this to be consistant and
just refer to trust anchors.

Jim

---

From: Scott Schmit <[email-masked]>
Date: Wed, 17 Aug 2011 00:10:06 -0400

> I was under the assumption that the reference type is always the identity reference or a hash. What other types can you think of?

URI
URN
Fingerprint

Anyway, all other things equal, it's just better not to close future
growth unnecessarily.

-- 
Scott Schmit

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 17 Aug 2011 11:27:50 +0200

> URN

How can these ever be cryptograpphicaly secure? 

> Fingerprint

That is a hash, right?

> Anyway, all other things equal, it's just better not to close future

Implementationwise, I believe it is good make things simple and limit the reference type to be either the identity or a hash.

	jakob

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Aug 2011 13:59:44 -0700

The reference type field can be thought of as a reference type - this would
be a statement of how you find the certificate in question.  Or it can be
through of as a matching rule, the certificate in question must have this
property in order to be acceptable.

I think that the concept of calling a hash of a certificate a "reference
type" leaves something to be desired as there is no way to find the
certificate from the hash unless you already have it.   However calling it a
matching rule makes sense because you can check if a certificate you already
have meets the criteria that has been laid out in the rule.

If this is the case, it is a matching rule rather than a location rule, then
it makes sense to have any number of different items here along with a set
of rules for matching.  Thus the proposal that I made of doing a public key
matching rule is possible.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Schmit
> Sent: Tuesday, August 16, 2011 9:10 PM
> To: [email-masked]
> > > 1.  The text makes the assumption at all new reference types are
> > > going to be hashes.  I do not agree that this is true statement.
> > > Therefore the second condition should be
> > >
growth
> unnecessarily.
> 
> --
> Scott Schmit
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane