Subject: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector

From: Ondrej Mikle <[email-masked]>
Date: Thu, 01 Dec 2011 18:02:30 +0100

Hi,

I've written a proposal for addition to "Security considerations" 
section covering what was said in the "Fragility of binding..." threads 
about association by SPKI and client-side PKIX validation. Possibly the 
"should's" are too strong for someone's liking.

---begin text---

DNS administrators SHOULD use selector type 1 (SubjectPublicKeyInfo) in 
TLSA records where certificate usage field is 0. Many TLS clients 
exchange intermediate certificates in chains sent by server while 
performing PKIX validation. Reason for such behavior is that CA 
certificates are often reissued: with different expiry dates, stronger 
hashing algorithm, etc. If the aforementioned TLSA record used selector 
type 0 (full certificate), it might cause interoperability problems for 
TLS client that swapped CA certificate for one with identical public key.

TLSA record with usage type 0 SHOULD NOT associate with a 
cross-certificate. TLS clients often cut certificate chain short once 
the client reaches an intermediate certificate which chains to a trust 
anchor in client's trusted certificate store. Association with a 
cross-certificate would be thus rejected by the client. It is 
RECOMMENDED that the association is made with a CA certificate that 
directly signed the leaf certificate since it gives the most predictable 
processing on client's side.

---end text---

Ondrej Mikle

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Dec 2011 09:09:08 -0800

First: thanks for providing text! It's so rare these days...

On Dec 1, 2011, at 9:02 AM, Ondrej Mikle wrote:

> I've written a proposal for addition to "Security considerations" section covering what was said in the "Fragility of binding..." threads about association by SPKI and client-side PKIX validation. Possibly the "should's" are too strong for someone's liking.

I generally really dislike 2119 language in "security considerations" because that is normative language. In this specific case, I think it is too strong anyhow, but can be managed easily.

> ---begin text---
> 
> DNS administrators SHOULD use selector type 1 (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0. Many TLS clients exchange intermediate certificates in chains sent by server while performing PKIX validation. Reason for such behavior is that CA certificates are often reissued: with different expiry dates, stronger hashing algorithm, etc. If the aforementioned TLSA record used selector type 0 (full certificate), it might cause interoperability problems for TLS client that swapped CA certificate for one with identical public key.
> 
> TLSA record with usage type 0 SHOULD NOT associate with a cross-certificate. TLS clients often cut certificate chain short once the client reaches an intermediate certificate which chains to a trust anchor in client's trusted certificate store. Association with a cross-certificate would be thus rejected by the client. It is RECOMMENDED that the association is made with a CA certificate that directly signed the leaf certificate since it gives the most predictable processing on client's side.
> 
> ---end text---

Instead, how about "DNS administrators should strongly consider using selector type 1 (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0 because many TLS clients...", with a similar type of change for the second paragraph?

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 1 Dec 2011 09:42:19 -0800

On Thu, Dec 1, 2011 at 9:02 AM, Ondrej Mikle <[email-masked]> wrote:
> Hi,
>
> I've written a proposal for addition to "Security considerations" section
> covering what was said in the "Fragility of binding..." threads about
> association by SPKI and client-side PKIX validation. Possibly the "should's"
> are too strong for someone's liking.

Thanks!  This was on my list of things to file as issues.

It seems to me that this is valuable to have, but it's not a
_security_ consideration.  Can I suggest that we add an "operational
considerations" section covering this and anything else that's useful
for operators to know but not security-critical?

zw

---

From: Warren Kumari <[email-masked]>
Date: Thu, 1 Dec 2011 13:09:42 -0500

> I've written a proposal for addition to "Security considerations" section covering what was said in the "Fragility of binding..." threads about association by SPKI and client-side PKIX validation.…

<chair hat>
Awesome, thank you for text, it makes discussions *much* clearer and consensus *much* easier to judge.
</chair hat>

> TLSA record with usage type 0 SHOULD NOT associate with a cross-certificate. TLS clients often cut certificate chain short once the client reaches an intermediate certificate which chains to a trus…

<no hats>
Hmmm, I like the text, but how would you feel about having this text in the "Operational Considerations for Deploying TLSA Records" section instead of the "Security Considerations" section?
It feels like it it more operational in nature to me....
</no hats>

W

> 
> Ondrej Mikle
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 1 Dec 2011 20:29:27 +0100

> It feels like it it more operational in nature to me....

That was my silly idea in a first place, since I didn't realize that we already have Operational Considerations when we talked about these issues today.  So I think that Operational Considerations are better place...

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondrej Mikle <[email-masked]>
Date: Fri, 02 Dec 2011 01:55:13 +0100

> Instead, how about "DNS administrators should strongly consider using selector type 1 (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0 because many TLS clients...", with a…

OK. I wasn't sure where the text belongs. So what about new subsection under
"Operational Considerations for Deploying TLSA Records" called "Provisioning
TLSA records with usage type 0" saying (normative language substituted):

---begin text---

DNS administrators should strongly consider using selector type 1
(SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0
because many TLS clients exchange intermediate certificates in chains sent by
server while performing PKIX validation. Reason for such behavior is that CA
certificates are often reissued: with different expiry dates, stronger hashing
algorithm, etc. If the aforementioned TLSA record used selector type 0 (full
certificate), it might cause interoperability problems for TLS client that
swapped CA certificate for one with identical public key.

When using certificate usage 0, association should not be made with a
cross-certificate. TLS clients often cut certificate chain short once the client
reaches an intermediate certificate which chains to a trust anchor in client's
trusted certificate store. Association with a cross-certificate would be thus
rejected by the client. In order to assure predictable results at client's side,
the association should be made with a CA certificate that directly signed the
leaf certificate.

---end text---

Thanks everyone for the feedback.

Ondrej Mikle

---

From: Peter Koch <[email-masked]>
Date: Sat, 3 Dec 2011 23:53:35 +0100

> because many TLS clients exchange intermediate certificates in chains sent by
[...]

I consider this type of language confusing. "should strongly consider" is
not formally normative because of the lack of capitalization but what is this advice
worth?  Given the elaborate reasoning that follows, wouldn't "RECOMMENDED"
be the appropriate level of direction?  Also, I'd suggest not to address
the "DNS administrator" because it's not necessarily their choice.

"The use of selector type 1 (SubjectPublicKeyInfo) is RECOMMENDED where the TLSA
record's usage field is 0 ..."

-Peter

---

From: Ondrej Mikle <[email-masked]>
Date: Sun, 04 Dec 2011 04:56:40 +0100

> record's usage field is 0 ..."

(Sorry for the length of following post, I've tried to cover every relevant case
I count think of.)

I admit I am new at writing RFCese. In first proposal I had "SHOULD, SHOULD NOT
and RECOMMENDED". Paul Hoffman felt that the normative RFC 2119 language was too
strong and suggested a replacement. I personally prefer the normative language
in this case, because the text aims to avoid hard-to-debug "cooperation paradoxes".

(Safe to skip this paragraph: Example of similar not-so-rare "cooperation
paradox" to-date: Some TLS servers do not send complete intermediate chain.
Though it works for server administrator when he checks and most clients, but
"strangely" fails for a few other clients - it's because TLS clients often cache
valid intermediate certificates, thus only fresh client installations tend to
encounter the failure-to-build-trust-chain problem. Even most IT admin folk
haven't heard about this caching/'transvalid' building-of-cert-chain behavior.
Which is why is it hard to for client to correctly report bug and the server
admin to understand and fix it.)

My goal is that this pitfall with unpredictable chain-of-trust building at
client's side is documented. I let the decision "normative" vs "plain" language
to more skilled RFC veterans. So I've written two versions, one normative, one
non-normative (just reminding that it's for "operational considerations" section):

---begin text normative version---

When deploying TLSA record with certificate usage field 0, it is RECOMMENDED to
use selector type 1 (SubjectPublicKeyInfo) in such TLSA record. Many TLS clients
exchange intermediate certificates in chains sent by server while performing
PKIX validation. Reason for such behavior is that CA certificates are often
reissued: with different expiry dates, stronger hashing algorithm, etc. If the
aforementioned TLSA record used selector type 0 (full certificate), it might
cause interoperability problems for TLS client that swapped CA certificate for
one with identical public key.

TLSA record with certificate usage type 0 SHOULD NOT associate with a
cross-certificate. TLS clients often cut certificate chain short once the client
reaches an intermediate certificate which chains to a trust anchor in client's
trusted certificate store. Association with a cross-certificate would be thus
rejected by the client. It is RECOMMENDED that the association is made with a CA
certificate that directly signed the leaf certificate since it gives the most
predictable processing on client's side.

---end text normative version---

---begin text non-normative version---

When constructing certificate usage field 0 in a TLSA record, the best course of
action is to use selector type 1 (SubjectPublicKeyInfo) in such TLSA record.
Many TLS clients exchange intermediate certificates in chains sent by server
while performing PKIX validation. Reason for such behavior is that CA
certificates are often reissued: with different expiry dates, stronger hashing
algorithm, etc. If the aforementioned TLSA record used selector type 0 (full
certificate), it might cause interoperability problems for TLS client that
swapped CA certificate for one with identical public key.

It is important to avoid associating TLSA record with certificate usage type 0
with a cross-certificate. TLS clients often cut certificate chain short once the
client reaches an intermediate certificate which chains to a trust anchor in
client's trusted certificate store. Association with a cross-certificate would
be thus rejected by the client. Best approach would be to make the TLSA
association with a CA certificate that directly signed the leaf certificate
since it gives the most predictable processing on client's side.

---end text non-normative version---

A possible reason to use full certificate in the certificate usage 0 case anyway
is when the site operator/admin/etc absolutely wants to ensure that extensions
of the certificate he chose needs to be preserved. I could think only of two
attacks that would be possible on bare SPKI compared to full-cert association:
DOS (e.g. using an expired CA cert in TLS MitM handshake) or exploiting some
X.509 implementation quirks of ASN.1 parsing issuing CA's software or in
clients. (I'm sure someone will come up with something else eventually; e.g. I
came accross a case where handling of few not-so-often used certificate
extensions varies widely among common clients).

Ondrej

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 4 Dec 2011 14:42:43 +0000

Hi Ondrej, Peter, folks,
For me, the normative form is best, as from this implementors know what
is intended in one (clear) sentence.

Personally, I'm really happy that it has an explanation/justification as
well. This is a Very Good Thing (many RFCs just let you guess the rationale,
IMHO forcing implementors [and product manager :] into guru meditation is risky).

One thing (editorial only) -- the proposed text is missing definite and indefinite
article(s). I read the first paragraph as including:
"A TLSA record", "the server", "The reason", "a TLS client", "the CA certificate",
"an identical public key".

I read the second paragraph as including:
"A TLSA record", "a certificate chain", "those clients' trusted certificate stores",
'the client' -> "such clients", 'client's side' -> "the client side".

So, Im a +1 for the normative form.

Quick question: what would it mean if there were to be more than one TLSA record
in the RRSet?

all the best,
 Lawrence

---

From: Scott Schmit <[email-masked]>
Date: Sun, 4 Dec 2011 16:16:28 -0500

On Sun, Dec 04, 2011 at 02:42:43PM +0000, Lawrence Conroy wrote:
> Quick question: what would it mean if there were to be more than one
> TLSA record in the RRSet?

Multiple associations are possible. Only one must be valid. This allows
cert/key rolling, multiple servers, certs/keys for different algorithms,
etc.

That said, the consensus call for the document edit includes the entire
paragraph as "old" and misses some of the processing after deciding that
the records have been recieved securely in the "new", namely: "if the
application doesn't understand it, drop it; iterate through each
remaining records until you find one that matches, otherwise abort."

My +1 is contingent on that latter bit still being in the new, since
that's what makes the document usable. :-) I trust that was an
oversight?

-- 
Scott Schmit

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 6 Dec 2011 10:41:42 +0100

Hi all,

any objections to adding this text to operational recommendations section?
I feel that the text was generally well received and thus no call is needed
(unless I hear from you now).

O.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 6 Dec 2011 11:43:34 -0800

I kind of read this text, despaired and then, because I was at the winery, shrugged off and tried to forget.

Issues that I have:

1.  I don't know how to identify cross-certificates and thus cannot figure out how to identify these in the second paragraph.

2.  A large part of the reasons that I would use a certificate with a usage field of 0 would be to force specific extensions to be used during the process of PKIX certificate validation.  This recommendation does not allow for that to be the recommended usage and thus gives me a problem.

3.  As was pointed out, rolling over CA certificates is not an issue as multiple TLSA records with a usage field of 0 can be in the DNS records.  This means that basing the behavior on the CA roll over case is probably not valid.

4.  I don't understand what is being said in the second sentence of the first paragraph.  I assume this came about as a result of the discussions dealing with the fact that the Msft code will actually re-build the certificate chain from scratch rather than use the one provided by the TLS server in its messages.  In the case of the Msft code, it will also return ALL of the chains that were found so that the client code can select the chain(s) that match the DANE restrictions if such a chain can be built to a trusted anchor.  The case where this would not be doable are going to be those cases which are, I think, addressed in the second paragraph where an alternative chain with a cross certificate (possibly issued by my corp) are found.

5.  It is not clear to me that the most predictable processing would be done by making the association on the CA closest to the client certificate as oppose to being on the most distant certificate.  What do you want to be able to be predictable?  The enforcement of the selected extensions chosen by the CA issuer or the ability to be any arbitrary chain that will get to some trust anchor?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ondrej Surý
> Sent: Tuesday, December 06, 2011 1:42 AM
> To: IETF DANE WG list
> Subject: Re: [dane] Addition to "Security considerations" section - usage type
> 0 with SubjectPublicKeyInfo selector
> 
> Hi all,
> 
> > When deploying TLSA record with certificate usage field 0, it is
> > RECOMMENDED to use selector type 1 (SubjectPublicKeyInfo) in such TLSA
> > record. Many TLS clients exchange intermediate certificates in chains
> > sent by server while performing PKIX validation. Reason for such
> > behavior is that CA certificates are often
> > reissued: with different expiry dates, stronger hashing algorithm,
> > etc. If the aforementioned TLSA record used selector type 0 (full
> > certificate), it might cause interoperability problems for TLS client
> > that swapped CA certificate for one with identical public key.
> >
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 22:24:46 +0100 (MET)

Jim Schaad wrote:
> 
> I kind of read this text, despaired and then,
> because I was at the winery, shrugged off and tried to forget.

While I do understand the technical problem, I do not really
understand the meaning of the proposed text.

> 
> Issues that I have:
> 
> 1.  I don't know how to identify cross-certificates and thus cannot
> figure out how to identify these in the second paragraph.

One of the PKIX folks recently told me that the term "intermediate CA"
is no longer used, and every CA cert that is neither self-signed nor
self-issued is called a cross-certificate.

> 
> 2.  A large part of the reasons that I would use a certificate with
> a usage field of 0 would be to force specific extensions to be used
> during the process of PKIX certificate validation.
> This recommendation does not allow for that to be the recommended
> usage and thus gives me a problem.

You can force 100% of the acceptable characteristics by
listing the server certificate that you're using.

The only reason not to list the server certificate but rather the
CA's certificate that signed the server's certificate is the lifetime
difference (the issuing CA's cert lifetime is typically 5-10 years whereas
the server's cert lifetime is typically 1 year (because markedroids
might change names or the company or business might be sold).

> 
> 3.  As was pointed out, rolling over CA certificates is not an issue
> as multiple TLSA records with a usage field of 0 can be in the
> DNS records.  This means that basing the behavior on the CA roll
> over case is probably not valid.

You're missing the point.  You may get your server cert issued with
a lifetime of 1 year when the remaining lifetime of the issuing CAs
cert is 1.5 years.  When the DNS zone is configured and the server
cert is installed on the server, the successor CA cert does not
even exist yet.  6 months later, a new issuing CA cert with an
extended lifetime is created (so that further server certs with
a lifetime of one year can be issued), and the renewed CA cert
slowly migrates onto clients of the installed base, some of which
cache such intermediate CA certs and reuse it for certificate path
discovery before validating server certificates. 

Server admins do not track such CA cert renewals, because the CA cert
that they send in their forward path has sufficient lifetime left on
it.  Anyhow there are TLS clients in the installed base that might
replace the CA cert sent by the server with a newer one they obtained
from another Web Server that they connected to.

> 
> 5.  It is not clear to me that the most predictable processing would
> be done by making the association on the CA closest to the client
> certificate as oppose to being on the most distant certificate.
> What do you want to be able to be predictable?  The enforcement
> of the selected extensions chosen by the CA issuer or the ability
> to be any arbitrary chain that will get to some trust anchor?

The problem here is that every client might built his certficate
chain individually different from any other client and different
from the server, so the only two things that are reliably predictable
for the server admin are the server certificate itself, and the
subjectpublickeyinfo that can be used to verify the signature
on the server certificate.  Everything else has the potential
to badly interfere with weird PKI cross-certifictations that
might be in use on some of the clients.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 6 Dec 2011 14:33:58 -0800

> From: Martin Rex [mailto:[email-masked]]
> Sent: Tuesday, December 06, 2011 1:25 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dane] Addition to "Security considerations" section -
> 
> Jim Schaad wrote:
> >
> > I kind of read this text, despaired and then, because I was at the
> > winery, shrugged off and tried to forget.
> 
> While I do understand the technical problem, I do not really understand
the
> meaning of the proposed text.
> 
> 
> >
> > Issues that I have:
> >
self-issued
> is called a cross-certificate.
> 

That would not be a definition that I would ever use.   The term cross-cert
means something very specific to me.  However if that were the case, then
the text would make even less since you would be "going through" a
certificate and that would not be a certificate - i.e. what you claim is now
referred to as a cross-cert.  I would probably just refer to it as a CA
certificate, but since I am old and inflexible I would also use the term
intermediate.  Looking at RFC 4949 - it still says that cross-certificates
are for use between different PKIs.  However, there is nothing in the
certificate itself which distinguishes it between a normal CA certificate
and a cross-certificate.

> >
> > 2.  A large part of the reasons that I would use a certificate with a
> > usage field of 0 would be to force specific extensions to be used
> You can force 100% of the acceptable characteristics by listing the server
> certificate that you're using.

I would disagree with this statement, but then I doubt that you care about
those extensions which are hierarchical in nature and therefore you believe
this to be a true statement.

> 
> The only reason not to list the server certificate but rather the CA's
certificate
> that signed the server's certificate is the lifetime difference (the
issuing CA's
> cert lifetime is typically 5-10 years whereas the server's cert lifetime
is
> typically 1 year (because markedroids might change names or the company
> or business might be sold).
> 

Or a situation where you might return different server certificates based on
the TLS handshake and don't want to overload the DNS with all of the
different possible server certificates you might be returning.

> > as multiple TLSA records with a usage field of 0 can be in the DNS
> > records.  This means that basing the behavior on the CA roll over case
> > is probably not valid.
> 
> You're missing the point.  You may get your server cert issued with a
lifetime
> of 1 year when the remaining lifetime of the issuing CAs cert is 1.5
years.
> When the DNS zone is configured and the server cert is installed on the
> server, the successor CA cert does not even exist yet.  6 months later, a
new
> issuing CA cert with an extended lifetime is created (so that further
server
> certs with a lifetime of one year can be issued), and the renewed CA cert
> slowly migrates onto clients of the installed base, some of which cache
such
> intermediate CA certs and reuse it for certificate path discovery before
> validating server certificates.
> 
> Server admins do not track such CA cert renewals, because the CA cert that
> they send in their forward path has sufficient lifetime left on it.
Anyhow
> there are TLS clients in the installed base that might replace the CA cert
sent
> by the server with a newer one they obtained from another Web Server that
> they connected to.
> 

And low and behold, if that is the case then some of the client software
will also say that there is not a valid path through the new certificate
since there is a school of thought which says that a certificate must be
properly nested in the time scale of its parent certificate.  I doubt that I
would have much sympathy for such a set of client software (either one).  So
you are assuming that you have a CA which does not change its keys, that the
TLS server does not send a certificate chain and you have a client cache
which can hold only one CA certificate for a given public key.  This seems
more brain dead than normal.

> > What do you want to be able to be predictable?  The enforcement of the
> > selected extensions chosen by the CA issuer or the ability to be any
> > arbitrary chain that will get to some trust anchor?
> 
> The problem here is that every client might built his certficate chain
> individually different from any other client and different from the
server, so
> the only two things that are reliably predictable for the server admin are
the
> server certificate itself, and the subjectpublickeyinfo that can be used
to
> verify the signature on the server certificate.  Everything else has the
> potential to badly interfere with weird PKI cross-certifictations that
might be
> in use on some of the clients.
> 

And thus the admin is banned from doing what they want to get the best
possible enforcement of the certificate policies that it is selecting - this
seems to be bad design.  The situation will be even worse if they happen to
use the usage 2 and people do cross certificates.  I thought that one of the
things that DANE was setup to avoid was the entire world of people issuing
cross-certificates that were not desired by the TLS site administrator.  Now
you are telling me that this is not of any interest at all.  Go figure.

jim

---

From: Ondrej Mikle <[email-masked]>
Date: Wed, 07 Dec 2011 17:09:37 +0100

> certificate itself which distinguishes it between a normal CA certificate

The term 'cross-certificate' was meant as described in RFC 4949, as you 
say (which I believe is the way the term is commonly used). I admit that 
it is difficult to describe it in technical terms, i.e. extra 
information is necessary than just the fields of certificate.

> this to be a true statement.

I wrote an informal comment before expressing that:

"A possible reason to use full certificate in the certificate usage 0 
case anyway is when the site operator/admin/etc absolutely wants to 
ensure that extensions of the certificate he chose needs to be preserved."

Would it make it more acceptable for you if a formalized version of the 
comment was added to the proposed text?

> more brain dead than normal.

The case I'm seeing more often is that client software swaps certificate 
for one having stronger hash function, but identical public key, issuer, 
subject and (almost) identical validity period (difference of one day). 
Note that in these cases the swapped certificate is client's built-in 
trust anchor and the TLS server sends proper chain.

> you are telling me that this is not of any interest at all.  Go figure.

No, the admin is not banned from using association with a full 
certificate. It is a recommendation to avoid breakage listing some of 
the reasons seen in actual deployment so that the admin can figure when 
to make an exception.

As I stated before, my goal is to have it documented; I don't insist on 
normative version.

Ondrej

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 Dec 2011 11:36:40 -0800

> Sent: Wednesday, December 07, 2011 8:10 AM
> To: [email-masked]

Ok - given that a cross-certificate would have the same key as the original
key.  How can one possibly enforce the SHOULD NOT in the first line of the
second paragraph?  I would think that the whole thing is to allow for a
cross-certificate if one specifies match by key.

> comment was added to the proposed text?

I think it would be more acceptable to give both sides of the argument in
terms of which option one would want to use and then to remove the normative
language.

> that

Are you suggesting this is a new certificate representing a known TA?  If so
then it would be more appropriate to have a usage type of 2 rather than 0 in
this case.  If the TA is a local certificate to the client then a whole
different set of problems ensue.   I would argue that there is a large
difference between talking about a generic CA certificate being re-issued
for various reasons and a TA certificate being re-issued for much the same
reasons.  If you want to discuss what happens when a TA certificate is
re-issued and how and administrator should handle that, that that is fine.
But please be clear exactly what cases you are addressing.

> the reasons seen in actual deployment so that the admin can figure when

Ok - but you are making a strong recommendation without given a suggestion
on when it would not be followed.  You are talking to people who are
probably not going to understand the subtleties of the issues and thus be
able to make good decisions.  They are going to generally blindly follow the
recommendation especially since it is stated in normative language.

Jim

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Dec 2011 15:30:54 +0100 (MET)

Jim Schaad wrote:
>Martin Rex wrote:

Thanks for the Pointer to rfc4949.  It reads (on bottom of that page):

  http://tools.ietf.org/html/rfc4949#page-156

  $ intermediate CA
      (D) The CA that issues a cross-certificate to another CA. [X509]
      (See: cross-certification.)

      Deprecated Term: IDOCs SHOULD NOT use this term because it is not
      widely known and mixes concepts in a potentially misleading way.
      For example, suppose that end entity 1 ("EE1) is in one PKI
      ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the
      root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2").
      Then, if EE1 constructs the certification path CA1-to-CA2-to-EE2
      to validate a certificate of EE2, conventional English usage would
      describe CA2 as being in the "intermediate" position in that path,
      not CA1.

Considering the definition of cross-certification (bottom of this page):

   http://tools.ietf.org/html/rfc4949#page-86

   $ cross-certification
      (I) The act or process by which a CA in one PKI issues a public-
      key certificate to a CA in another PKI. [X509] (See: bridge CA.)

      Tutorial: X.509 says that a CA (say, CA1) may issue a "cross-
      certificate" in which the subject is another CA (say, CA2). X.509
      calls CA2 the "subject CA" and calls CA1 an "intermediate CA", but
      this Glossary deprecates those terms. (See: intermediate CA,
      subject CA).

this looks inconsistent to me, and create the impression to delibertately
sneak a PKI architectural change past implementors and protocol designers.

-Martin

---

From: Ondrej Mikle <[email-masked]>
Date: Mon, 12 Dec 2011 15:59:51 +0100

I'll write a new non-normative version. I'll just need to get two issues 
clear (see inline comments below).

> cross-certificate if one specifies match by key.

I see your point. I'll break it down to two cases (CA1 issues 
cross-certificate to CA2):

- case 1: association to cross-certificate with selector type 0 (full 
certificate) - clients are known to cut chains in this case, such 
association would be discouraged

- case 2: association with selector type 1 (SPKI) which happens to match 
other CA2 (root) certificate as well as a cross-certificate issued by 
CA1 to CA2 - I don't see a problem here

> But please be clear exactly what cases you are addressing.

It's happening in both cases: the "generic CA cert case" and the "TA 
cert case" (the latter being more common).

The "TA case" seems to be less predictable in respect to processing at 
client side:
There exist two 'versions' of a CA certificate: deprecated certificate 
C1 with obsolete hashing algorithm and certificate C2 with stronger 
hashing algorithm. Many servers still send certificate chain containing 
the deprecated C1. Some clients will accept C1 as trust anchor, while 
other swap it for C2. (Certificates with obsolete hash algorithm in 
signature algorithm are being slowly phased out from clients' trust 
stores, but at different rate.)

Ondrej

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 12 Dec 2011 16:12:54 -0800

> From: Ondrej Mikle [mailto:[email-masked]]
> Sent: Monday, December 12, 2011 7:00 AM
> To: Jim Schaad
> Cc: [email-masked]
clear
> (see inline comments below).
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Ondrej Mikle
> >> The term 'cross-certificate' was meant as described in RFC 4949, as
> >> you say (which I believe is the way the term is commonly used). I
> >> admit that it is difficult to describe it in technical terms, i.e.
> >> extra information is necessary than just the fields of certificate.
> >>
> >
> > Ok - given that a cross-certificate would have the same key as the
> > original key.  How can one possibly enforce the SHOULD NOT in the
> > first line of the second paragraph?  I would think that the whole
> > thing is to allow for a cross-certificate if one specifies match by key.
> 
cross-certificate to
> CA2):
association
> would be discouraged

Tell me again what the goal of the working group is.  

My first thought is that if CA2 is the root cert that is being used by the
host, then I would expect it to potentially be setup as a trust anchor
record and thus you example above could be moot.

I don't know that case 1 should be discouraged or encouraged.  It should be
stated what the goal of the administrator is.  From that which case to be
used would fall out.

> 
> >> The case I'm seeing more often is that client software swaps
> >> certificate for one having stronger hash function, but identical
> >> public key, issuer, subject and (almost) identical validity period
(difference
> of one day).
> > Are you suggesting this is a new certificate representing a known TA?
> > If so then it would be more appropriate to have a usage type of 2
> > rather than 0 in this case.  If the TA is a local certificate to the
client then a
> whole
> > difference between talking about a generic CA certificate being
> > re-issued for various reasons and a TA certificate being re-issued for
> > much the same reasons.  If you want to discuss what happens when a TA
> > certificate is re-issued and how and administrator should handle that,
that
> that is fine.
> It's happening in both cases: the "generic CA cert case" and the "TA cert
> case" (the latter being more common).
> 
client
> side:
hashing
> algorithm. Many servers still send certificate chain containing the
deprecated
> C1. Some clients will accept C1 as trust anchor, while other swap it for
C2.
> (Certificates with obsolete hash algorithm in signature algorithm are
being
> slowly phased out from clients' trust stores, but at different rate.)

Unless the C1 has been revoked, one can hardly say it is deprecated.  It is
still a completely valid certificate.

I agree that this is the case.  Again, what is the problem that the DANE
working group is trying to solve?  What is the attack case that mimics this
same situation and one is trying to prevent.  When looking at trust anchors,
I tend to be much looser about what is in the self-signed certificate as in
this case many systems will ignore the extensions anyway in favor of local
configuration and just worry about what the key value is.  This would mimic
using the SPK as the matching point.  But this would be in the context of a
trust anchor statement and not a CA statement.