Subject: [keyassure] Interpreting certificates (and summary)

From: Scott Schmit <[email-masked]>
Date: Mon, 21 Feb 2011 09:45:27 -0500

[Partly a summary, partly an attempt to re-focus the conversation.]

I think we can all appreciate that complexity is the antithesis of
security, and simpler is better. There have been a significant number of
vulnerabilities in ASN.1 and X.509 parsing, and there will probably be
more. And I've also seen expressed (though I can no longer find the
webpage that went through the problems) that X.509 is a disaster because
rules for parsing and certificate generation are so ambiguous or
inconsistent that clients must violate the spec to work in the real
world. Even if the specs have been fixed, there is almost certainly
still stuff out there that hasn't changed.

So, it's entirely believable that some people decided that this was just
too much trouble and came up with their own solution (e.g., SSH). With
DNSSEC providing a secure place to associate keys with nodes, one could
imagine future protocols (or existing ones) being interested in using
the DNS, and DANE seems like a good mechanism for that.

And this is is the attraction of bare keys--in DNSSEC, you have a chain
of DS records and DNSKEY records linked to some domain name, all
authenticated using RRSIG records. So clearly, DNSSEC already can do
certificates (in the sense of a binding of a name to a key), we just
need a generic way for applications to use that mechanism.

While our current focus is TLS/DTLS, general but simple solutions are
usually the better ones, so that's another reason for the call for bare
keys--it seems so much simpler.

Even if you accept all that (and you may not), TLS/DTLS uses X.509
certs.  Listening to Peter, I have a better appreciation now that
because the TLS protocol has no native way to say "here's my key, check
out of band to see if you trust it", the existing code doesn't provide
the right kind of capabilities or interfaces for the programmer to do
that reliably, as there was no requirement at the time for such a
feature.

If we want to see DANE adopted in the near future (or at all) in
protocols that already exist (i.e. using TLS), we must respect that a
lot of people aren't going to see the security benefits of DANE being
worth starting from scratch or significantly rewriting existing, working
security libraries (and all the risks that implies).  That said, the
error paths of those libraries are going to take more of a beating, now
that CAs with a reputation to protect aren't sanitizing the certificate
fields.

Even if we reuse pieces of what's there, they're still invasive changes
to ASN.1/X.509 parsing code--the very stuff that has had all those
problems. Also, the non-DANE case isn't going away overnight, so both
cases must still be covered (complicating the logic), and the more
difficult DANE is to adopt, the less overnight it'll be.

So I would suggest (and I have no hat, it's just a suggestion) that the
question of bare keys be put aside for the moment. To go with PKIX
certificates, we need to deal with the problem that PKIX certificates
have fields that duplicate what DNSSEC is telling the relying party.
And duplication of information means an opportunity for that information
to conflict.

Looking at some typical certs, here are some sources of conflict I see:
* Subject identification (including alt names) vs domain name [???]
* Validity vs RRSIG period [take the min period]
* Name constraints vs domain name [???]
* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]
* CA flag, path length, etc vs the dane-04 cert type [???]

Other tricky things to resolve:
* How do EV certs fit in? (Whatever rules we come up with to process
  subjects can't break the link to EV certs or make it over-permissive)
* Are there any other PKIX fields that clients use and trust, but are
  only trustworthy if issued by a third party?
* Are the changes to certificate validation required to made DANE
  meaningful just as bad as or worse than adding support for bare keys?
  (This won't be evident until we answer the above, which is part of why
  I suggest setting aside the bare key question.)

An item for security considerations:
* Now that CAs aren't necessarily issuing these certs, the client needs
  to be much more careful in its parsing (the null terminated vs length-
  delimited string bug comes to mind)

I'm sure there are other issues, too, but that's a start.

[I hope this helps & fairly represents everyone's positions.]

-- 
Scott Schmit

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 08:36:33 -0800

There is plenty of ambiguity in PKI, but it comes from the complexity of the
tasks and the constraints of the implementations.

The idea that these issues are going to go away because of a syntax change
or a move to DNSSEC is wishful thinking.

We had this particular fight fifteen years ago. I was on the other side at
the time. The last time there was a serious effort to make a change was in
1999 when VeriSign commissioned me to write an XML based spec for certs that
eventually became the foundation for SAML.

Having seen implementation of SAML grow to at least the same degree of
complexity as PKI, this strikes me as a profoundly pointless exercise.

At best it is going to add an option to the spec which Peter has already
indicated he has no interest in implementing or maintaining. Since he is the
maintainer of the main code base here and this issue is primarily one of
code complexity, I think this is rather more his call than that of the
group.

Adding DNSSEC into the code base is going to be a big enough increase in
code complexity as it is.

On Mon, Feb 21, 2011 at 6:45 AM, Scott Schmit <[email-masked]> wrote:

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

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Feb 2011 14:35:32 -0500 (EST)

On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

> Adding DNSSEC into the code base is going to be a big enough increase in code complexity as it is.

https://mattmccutchen.net/cryptid/nss-dane-20110215.patch

12 files changed, 362 insertions(+), 1 deletions(-)

Matt showed it was far from complex.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 11:48:49 -0800

On the contrary,

What he has shown is that the changes to SSL are minor,  *after adding
in the DNSSEC resolver library*

I just pulled down the Windows binary from http://unbound.net/, it is 5.3 Mb.

Now that may not seem complex to you but it certainly does to me. And
it is still going to be a lot of additional complexity if that can be
reduced to the 50kb or so that is round about where it should be.

security/nss/README.dane           |   78 +++++++++++++
 security/nss/cmd/tstclnt/tstclnt.c |    7 +-
 security/nss/lib/ssl/config.mk     |    3 +
 security/nss/lib/ssl/manifest.mn   |    1 +
 security/nss/lib/ssl/ssl.def       |    6 +
 security/nss/lib/ssl/ssl.h         |    3 +
 security/nss/lib/ssl/sslauth.c     |    9 ++
 security/nss/lib/ssl/ssldane.c     |  218 ++++++++++++++++++++++++++++++++++++
 security/nss/lib/ssl/sslerr.h      |    7 +
 security/nss/lib/ssl/sslimpl.h     |    4 +
 security/nss/lib/ssl/sslsecur.c    |   26 +++++
 security/nss/lib/ssl/sslsock.c     |    1 +
 12 files changed, 362 insertions(+), 1 deletions(-)

diff --git a/security/nss/README.dane b/security/nss/README.dane
new file mode 100644
index 0000000..ecbf442
--- /dev/null
+++ b/security/nss/README.dane
@@ -0,0 +1,78 @@
+This modified version of NSS contains a proof-of-concept implementation of the
+draft DANE protocol (see https://tools.ietf.org/wg/dane/) for DNSSEC-based
+authentication of TLS services.  The implementation uses the libunbound DNSSEC
+stub resolver (http://unbound.net/).  It is far from ready for production or
+upstream consideration, but it should be fun for experimentation.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Feb 2011 16:11:27 -0500 (EST)

On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

> On the contrary,
>
>  What he has shown is that the changes to SSL are minor,  after adding in the DNSSEC resolver library
>

That's the server. If you want to compare raw sizes (which is silly to begin with but ok), then use:

-rwxr-xr-x. 1 root root 807880 Jan 25 17:19 /usr/lib64/libunbound.so.2.8.0

On windows, I assume that a DNSSEC resolver library will come with the OS in the near future, so no
additional bytes are added.

Anyway, Henry Story also did a nice write up showing code complexity is a red herring when it comes
to supporting bare public keys - because that was your argument, that a new format of bare public
keys couldn't be done because the already complicated addition of DNSSEC validation in a TLS stack
that has to support DANE.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Feb 2011 16:13:56 -0500 (EST)

On Mon, 21 Feb 2011, Scott Schmit wrote:

> question of bare keys be put aside for the moment.

Agreed.

> * CA flag, path length, etc vs the dane-04 cert type [???]

I believe for DANE not to be reduced to the security of PKIX, DANE should
be able ignore all of these. Otherwise DANE just becomes a vehicle for
PKIX extensions like CAA - those might be a useful side effect, but not
the main goal of DANE, which is to level DNSSEC for TLS services. But
this is easilly done by not specifying those properties in your certificate.
It needs no DANE protocol support.

When specifying CRLs or OCSP or EV in the certs, and certifying the cert
in DANE, these properties become validatable by DANE provided the Issuer
can be validated as well - but in this case just DANE should not be enough,
as DANE cannot speak for items like EV.

>  delimited string bug comes to mind)

Uhm no. Any code should already have taken everything into account. Such
asusmptions caused the wildcard signed cert and the \0 CN. If the client
trusted the CAs for this, it was already very broken. It is precisely
why some rather trust their DNSOPS then any of the CA orgs, and is the
reason why more respected CAs want to limit the impact of less respected
CAs using DNSSEC validation.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 16:02:04 -0800

> additional bytes are added.

Ah so complexity in the operating system does not count?

If you are going to pull that one, then your whole argument falls because
X.509 is built into the core of Windows and has been for a decade. So by
your measure the complexity of X.509 does not count either.

I get rather fed up of this form of argument where issues that affect all
forms of PKI are to be held against X.509 and discounted or ignored as far
as your alternative proposal goes.

We are proposing an alternative code path here. That is inevitably going to
result in a net increase in the complexity of the system, unless the code
paths are rejected in their entirety.

The only way that an existing legacy infrastructure can be made simpler is
to profile and subset. That is often valuable work. And efforts like DANE
can provide features that enable a future simplification step. But that lies
far in the future, in the near term the result will be more complexity.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Feb 2011 19:36:47 -0500 (EST)

[ silly bytes discussion ]

> I get rather fed up of this form of argument where issues that affect all forms of PKI are to be held against X.509 and discounted or ignored as far as your
> alternative proposal goes.

That's because you yourself are not consistent, don't shoot the
messenger. You can't selectively claim 20 years of operational experience
as an asset in every other email, yet complain when that same operational
experience, and the inherit faults of those systems of the last 20 years
are pointed out. Faults which are the reason for developing a DANE system.

Also, I never heard you argue against CAA because it adds "bytes and
complexity" to the resolver code and TLS client. So clearly the situation
is a little more broad then 5MB of windows binary.

In other words, you are cherry picking your arguments. Others have already
stated that implementing bare public key at worst is a subset of ASN.1,
so let's just drop this whole "added complexity is not justified".

That discussion can be had when we have a draft for TLS bare public key.

And like others have stated here, the minimum we need to do for DANE
now is to ensure that if such a TLS method is added, TLSA will be able
to add support for it without a total rewrite.

> We are proposing an alternative code path here. That is inevitably going to result in a net increase in the complexity of the system, unless the code paths
> are rejected in their entirety.

So you are arguing that CAA should be dropped as well?

> 
> The only way that an existing legacy infrastructure can be made simpler is to profile and subset. That is often valuable work. And efforts like DANE can
> provide features that enable a future simplification step.

Indeed, and bare public key is one of the items people are looking at
to vastly simplify for the immediate future.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 17:43:07 -0800

On Mon, Feb 21, 2011 at 4:36 PM, Paul Wouters <[email-masked]> wrote:

> messenger.

No, I am not shooting the messenger, I am finding him to be hopelessly
biased, ill informed and confused.

> You can't selectively claim 20 years of operational experience
> are pointed out.

I complain that your comments are biased and poorly informed. I am aware
that there are issues with PKIX, there are issues with all deployed
protocols. But I also take the time to understand the reasons behind the
issues.

> Faults which are the reason for developing a DANE system.
>

The operational experience comes from people implementing and using the
system. I don't see any real difference in the architecture, the syntax or
the people involved. Insanity is doing the same thing twice and expecting a
different result.

ASN.1 is a real dog to implement. I know, I have implemented several DER
encoders and parsers and it is just abominable. But so is the DNS  record
format.

PKIX path math is tedious, but so is DNSSEC chain validation. Now you can
make PKIX path math considerably worse than DNSSEC chain validation, but to
do so you have to implement the set of features whose sole purpose is to
keep government contractors in business.

> is a little more broad then 5MB of windows binary.

CAA should do its job without adding a single line of code to any client or
server library.

The only parties that are required to implement CAA are CAs. Nobody else
need write a single line of code. If the scheme works correctly it should
deter CAs from mis-issue and give them the tools to avoid doing so at the
same time.

There is a client side capability in CAA, and that is certainly something
that would be very useful to have. But that functionality should only ever
be relevant when we are having the type of events we have been having in the
past few weeks when governments have actually been out co-ercing Internet
technology providers.

> so let's just drop this whole "added complexity is not justified".

Not at all, I actually bothered to talk about this with the code maintainer
last week. I also have rather more experience with the range of code
libraries that are used. TLS libraries that currently exist have APIs that
assume that an X.509/PKIX certificate will be offered during the initial TLS
handshake.

> That discussion can be had when we have a draft for TLS bare public key.

Well this is the wrong WG to go to for that. If you want to do bare key in
TLS then you should go to the TLS list and see what type of reception you
get.

> So you are arguing that CAA should be dropped as well?

First CAA does not mandate client code.

Second, I have never sold CAA as being a mechanism to simplify PKI code.
Thus a minor increase in complexity of the code is irrelevant for my
proposal but fatal for yours where the only intended purpose is a purported
reduction in code complexity.

If I propose using motor oil as a lubricant in my car, the fact that it does
not taste good as a desert topping for jello is not relevant. If on the
other hand you are proposing an alternative lubricant on the basis that it
can be used as a desert topping, the fact that it tastes terrible and is
probably carcinogenic is rather relevant to the debate.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 20:38:43 -0500

>still stuff out there that hasn't changed.

A few problems with ASN.1 parsing in some libraries were identified, 
and rectified, many years ago. This does not seem to be a current 
problem.

I know of no "ambiguities" in X.509 cert formats that cause problems. 
(Which is not to say that some CAs and some RP software have bugs 
:-). it's SW.)

For DANE we should generate a profile indicating what extensions MUST 
be present, MUST be omitted, MAY be present, etc.  We also can limit 
the
types of values allowed in standard cert fields, to further simplify
generation  and parsing. This is what we did for SIDR.

>the DNS, and DANE seems like a good mechanism for that.

SSH has an option to use X.509 certs :-).

>need a generic way for applications to use that mechanism.

DNSSEC does have a way to distribute keys; nobody is arguing against that.
The question is whether it's worth the trouble to modify apps that 
know how to use certs to use bare keys instead.

>keys--it seems so much simpler.

The apparent simplicity may not prevail when viewed in the larger app context.

>that reliably, as there was no requirement at the time for such a

yes.

>that CAs with a reputation to protect aren't sanitizing the certificate

Not sure what you mean here by "sanitizing."

>difficult DANE is to adopt, the less overnight it'll be.

What non-DANE cases do you have in mind?

>And duplication of information means an opportunity for that information

Agreed. We need to decide whether we want to compare redundant fields, or
ignore cert fields in favor of DNS data, or whatever.

>* Subject identification (including alt names) vs domain name [???]

the preferred Subject name for TLS is a DNS SAN. we have accommodated several
hacks in the Subject DN field for backward compatibility, but for any 
user-generated certs this ought mot be an issue.

>* Validity vs RRSIG period [take the min period]

This need mot be an issue. You will process the DNS TTL first, and reject
the record if it is expired. If the TTL is OK, then why not process the
cert validity interval separately, when performing cert path validation.

>* Name constraints vs domain name [???]

If the cert is used as a TA, this extension need not be processed.  (This
is a pet peve of mine, as I think it should, but the X.509 and PKIX specs
do not require such behavior.)

>* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]

TTL is not really equivalent to a CRL or OCSP. It is analogous to the
cert validity interval. The question here is whether a cert retrieved from
the DNS is a TA, or not.  if it is, then it will not be revoked via a 
CRL or OCSP, buy the very nature of a TA. But, if the cert is not a 
TA, the
question of what sort of revocation mechanism is used is relevant.

>* CA flag, path length, etc vs the dane-04 cert type [???]

The Basic Constraints extension needs to be present in a CA cert, but
the path length field is rarely used, and I would profile it away for DANE.

>   subjects can't break the link to EV certs or make it over-permissive)

I don't understand the context here. Are you talking about sites that 
have EV certs and want to also use DANE mechanisms?

>   only trustworthy if issued by a third party?

good question.

>   I suggest setting aside the bare key question.)

depending on what DANE does, this could be very easy, or not so trivial. If
we profile DANE certs to be simple, and use them only as TA material, 
this might be very easy.

>   delimited string bug comes to mind)

Peter Gutman has a large collection of mangled certs issued by "real" CAs, so
defensive parsing has always been appropriate.

Steve

---

From: Scott Schmit <[email-masked]>
Date: Mon, 21 Feb 2011 23:43:58 -0500

On Mon, Feb 21, 2011 at 08:38:43PM -0500, Stephen Kent wrote keyassure:
> For DANE we should generate a profile indicating what extensions
> MUST be present, MUST be omitted, MAY be present, etc.  We also can
> limit the types of values allowed in standard cert fields, to further
> simplify generation  and parsing. This is what we did for SIDR.

This assumes that the only certificates that you're interested in using
with DANE are newly-generated self-signed certificates. What does a web
site like Amazon or IETF do if they don't want to break existing users
that don't have DANE support and don't want to setup dane.amazon.com or
dane.ietf.org? If the rules defined for DANE-compatible certs happen
to be what they already have, then great, but will that work for all the
existing certs out there?

I could also imagine putting a CA certificate in the DNS so that the
organization doesn't need to deal with renewing the CA cert and also
updating the DNS. EEs have no control over the CA's certs.

> The apparent simplicity may not prevail when viewed in the larger app

I agree. Hence "seems" :-)

> Not sure what you mean here by "sanitizing."

Not letting the nasty stuff through. Not saying they never make
mistakes, but stuff that causes outright vulnerabilities I would imagine
they fix (even if it takes a public shaming first).

> What non-DANE cases do you have in mind?

The status quo today--the world without DANE.

> cert validity interval separately, when performing cert path validation.

I probably misstated my intent. What you described is what I meant. It's
probably better stated as "obey both".

> the DNS is a TA, or not.  if it is, then it will not be revoked via
> a CRL or OCSP, buy the very nature of a TA. But, if the cert is not
> a TA, the question of what sort of revocation mechanism is used is
> relevant.

I shouldn't have put TTL there. Martin Rex points out TTL isn't covered
by DNSSEC (and how can it be? it's supposed to count down!), so for as
long as the RRSIG is valid, an attacker can simply keep resending the
same record any time the TTL expires. Instead, it's RRSIG (or something
else).

While you're right that the RRSIG period is basically a validity period,
it's also not quite the same because of who is doing the signing. With
CAs today, no one would tolerate a validity of two weeks because they'd
need to get a cert reissued from the CA constantly. On the other hand,
shorter periods are typical in DNSSEC. By having the signing keys,
making the RRSIG period be short isn't so onerous as long as you can
automate the process.

> the path length field is rarely used, and I would profile it away for DANE.

Which works for new certs but not existing ones.

> I don't understand the context here. Are you talking about sites
> that have EV certs and want to also use DANE mechanisms?

Yes.

-- 
Scott Schmit

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Feb 2011 12:02:27 -0500 (EST)

On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

> CAA should do its job without adding a single line of code to any client or server library.
> 
> The only parties that are required to implement CAA are CAs.

So the CAA record meant to protect against bad CAs will only be used by CAs?

Odd. I thought it was clients checking the CAA record to see if the record authorized
a particular CA for signing the cert for the server.....

> Nobody else need write a single line of code. If the scheme works correctly it should deter CAs
> from mis-issue and give them the tools to avoid doing so at the same time.

If the CAA record is only meant for CAs to "deter" them from being bad CAs, then I have to
voice against the draft after all.

> There is a client side capability in CAA, and that is certainly something that would be very useful to have. But that functionality should only ever be
> relevant when we are having the type of events we have been having in the past few weeks when governments have actually been out co-ercing Internet
> technology providers.

Reality check. This is the only use of the CAA record. To protect against bogus CAs on the
client side.

> Well this is the wrong WG to go to for that. If you want to do bare key in TLS then you should go to the TLS list and see what type of reception you get.

I already stated that I have no problem leaving out bare public key in TLSA until we have one,
but what DOES need to be taken into account by this WG and the TLSA draft is a design that
allows this to be later put in as a TLSA type. To which you replied with 5.8MB EXE files.

If you are okay with taking into account that TLSA should be able to support a bare public key
type in the future, we're done with this discussion. If not, then please come up with why it
is harmful to the current TLSA draft to take this into account. Please try to come up with
short bullet point style concrete reasons, and avoid talking about 20 years of experience,
arguing from authority, or going of in 3 paragraph generalities about policy making.
(bonus points for not mangling the reply quoting characters as shown below)

> First CAA does not mandate client code.

See above. CAA without client verification is snake oil.

> Second, I have never sold CAA as being a mechanism to simplify PKI code. Thus a minor increase in complexity of the code is irrelevant for my proposal but
> fatal for yours where the only intended purpose is a purported reduction in code complexity.

You know that some (including me) are looking at not using any PKIX in the future. That is
a strong reduction in code complexity and a strong reduction root trust anchors. It is a
very valid security concern that PKIX has not managed to address in 20 years.

I was not accusing you of using CAA to simplify PKI. I brought it up to show that adding a few
lines of code to an overly complex PKIX system actually can make it stronger, just like adding
a few lines of DNSSEC validation can make TLS a lot stronger.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 15:27:49 -0500

> a particular CA for signing the cert for the server.....

Well maybe you should read the spec.

CAA means that CAs that mis-issue against an explicit instruction will have
been clearly an unambiguously at fault. The checks can be automated.

Either a CA is going to have to comply with instructions in CAA or it is
going to find that it's roots are rejected by the browser providers. So I do
not expect there to be a very significant population of non-compliant
certificates and hence the value of client side checking is likely to be
rather small.

It is still worth making the check in new code. But CAA delivers immediate
benefit to all browser users irrespective of whether they update their
browser or not.

You can implement the client side checks if you want to. But the effect
should be achieved without widespread client side deployment.

If you are okay with taking into account that TLSA should be able to support
> a bare public key
> type in the future, we're done with this discussion.

Well oddly enough, CAA actually has that capability already.

Since TLS has the ability to use other cert types it certainly makes sense
to have the ability to propose extensions to support them in DANE, including
bare key.

The current draft already has that.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Feb 2011 15:56:58 -0500 (EST)

On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> Since TLS has the ability to use other cert types it certainly makes sense to have the ability to propose extensions to support them in DANE, including bare key. 

Thanks.

> The current draft already has that.

But there were issues raised that the types in section 2.2 would not facilitate non-RSA public keys, such as ECC.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 17:25:05 -0500

Well you would have to design a packaging format, which as Peter explained
is going to mean ASN.1 for all practical purposes.

ASN.1 is what the cryptomodules spew out. And over time that is going to be
how most public key ends up being implemented.

And once we get into ECC issues, the difficulty of ASN.1 encoding really is
moot, as is the problem of signature or cert size.

I could see the point of this if you think we would be moving to a new cert
format before we move beyond RSA2048. But once we are in ECC land we have
compact signatures and short keys and the added overhead of the cert
signature is no longer important.

So yes, it can be supported and I would not want to see the draft actually
foreclose that option for future development. But I can't see it being very
useful either.

On Tue, Feb 22, 2011 at 3:56 PM, Paul Wouters <[email-masked]> wrote:

> But there were issues raised that the types in section 2.2 would not
> facilitate non-RSA public keys, such as ECC.
>
> Paul
>

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Feb 2011 23:40:29 +0100 (MET)

> how most public key ends up being implemented.

If there was an urgent necessity to represent bare keys in a protocol,
I personally would also appreciate if it recycled the ASN.1 DER of
subjectPublicKeyInfo from PKIX/X.509.

Implementing XMLdsig KeyValue conversions to make that stuff usable
with common crypto toolkit APIs is a royal PITA -- so no, I really
don't want to see yet another public key format standardized just
to ensure that again absolutely no-one will be able to reuse existing code.

The issue with existing X.509 parsers is that they usually decompose
then entire cert and do not return subjectPublicKeyInfo as an
ASN.1 DER blob.

While in theory, it should be possible to ASN.1 re-encode -- I would
be careful.  There are CAs out there with defective PKI-Software,
distributing X.509 certs that are not valid ASN.1 DER.

One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,
used to be incorrect ASN.1 DER (IIRC, incorrect encoding of
the unused KeyUsage bits).  Which is probably one reason why some ASN.1
decoders keep an original copy of the ASN.1 DER ToBeSigned around for
decoded X.509 certs...

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 18:17:27 -0500

On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex <[email-masked]> wrote:

> distributing X.509 certs that are not valid ASN.1 DER.

Give people options where getting it wrong will not cause the software to
fail and some people will get it wrong.

> decoders keep an original copy of the ASN.1 DER ToBeSigned around for

Since none of the roots was DER encoded until quite a few years in, this has
always been true. If you want a cert to work you have to keep the original
binary.

Given that a cert has never been as large as a maximal TCP packet, I have
never considered canonicalization or DER encoding to have any value
whatsoever. It is simply an idiot idea that came up in an X.500 committee
when there was an idea that certs would be stored in X.500 directories.

All that is necessary in a certificate is that the signature validates the
bits presented. It is not a problem if the same semantics could have been
encoded in other bits.

I don't see much value in XML canonicalization either.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 18:25:53 -0500

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 23 Feb 2011 21:08:27 +1300

Martin Rex <[email-masked]> writes:

>While in theory, it should be possible to ASN.1 re-encode -- I would be
>careful.  There are CAs out there with defective PKI-Software, distributing
>X.509 certs that are not valid ASN.1 DER.

You never, ever try to re-encode certs, because waaaay too many of them break
if you try it.  This has been standard practice for about 15-20 years now, the
rule of thumb is "there is only one (re-)encoding rule and its name is
memcpy()" (with a corollay of "there is only one X.500 name comparison rule
and it's name is memcmp()").

Peter.

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Feb 2011 19:57:28 +0100 (MET)

>   delimited string bug comes to mind)

This sounds somewhat strange to me.

When doing TLS authentication of a peer, the peer's certificate
is always untrusted at the time when it is parsed.  Parsing the
received X.509 cert is a prerequisite to being able to validate
the cert and determining whether it is trusted/trustworthy or not.

An ASN.1 parser that is not careful is an unconditionally bad idea
and asking for trouble; lots of trouble.  Tolerance to common
bugs of encodings produced by peers should never be accepted
"by accident", only by conscious trade-off decisions that are
clearly documented for the caller/consumer of the technology.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Feb 2011 14:45:31 -0500

BER encoding is supported by practically every ASN.1 library. It is
identical semantically to DER which is a pain in the patootie.

>From a drafting perspective, I would first state that the identifier
corresponds to an X.509v3 cert without mentioning encoding at all.

Then I would follow that with a statement that the TLS protocol requires
certificates to conform to the X.509v3 requirement for DER encoding and the
requirements of the PKIX certificate profile.

Specifying X.509v3 in DER encoding may appear to be more precise and less
ambiguous, but might well actually introduces ambiguity since another
interpretation of the statement is that there should be an additional ASN.1
structure wrapping the cert.

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Feb 2011 21:39:32 +0100 (MET)

It seems were quoting / replying to the wrong mail.

> corresponds to an X.509v3 cert without mentioning encoding at all.

I don't think that mentioning the encoding creates a problem.  My main
concern at this point was about "DER" alone rather than "ASN.1 DER".

> requirements of the PKIX certificate profile.

Which is pretty much plain wrong.  ;-)

Nothing in TLS precludes the use of X.509v1 certs,
The last sentence of Section 1 of all TLS documents (2246,4346,5246) reads:

                         The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

Which clearly explains that PKIX is just one possible approach to
interpreting the certificates exchange -- and definitely not the
only one.

Similarily, RFC-2818, the informational RFC which describes how
"HTTP Over TLS" is commonly performed says this:

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.)

Which describes a case where the TLS server certificate matching
is a PKIX-free memcmp() on X.509 certificates.

> Specifying X.509v3

If you keep sticking the v3 onto X.509, then you're creating
a necessity for a bare public key format.

While I'm pretty sure that self-signed end-entity X.509v1 certs
interoperate with all TLS implementations I've tested, I'm not aware
of a definition of a self-signed EndEntity X.509v3 cert (that isn't
in conflict with some version of X.509v3).

>                    in DER encoding may appear to be more precise and less

If there was a wrapping ASN.1 structure, it would be named and its
ASN.1 definition appear in an Appendix of the document.  I don't think
that the document will grow the necessary level of ambiguity for this
to happen.

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 23 Feb 2011 13:03:58 -0800

Could we short-circuit this entire argument by deferring to the
protocol being secured for the certificate format?  Concretely,
wording like

      [...] The types defined in this document are:

         1 -- An end-entity certificate, in the wire format used by
the protocol being secured
         2 -- A certification authority's certificate, ditto

zw

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Feb 2011 14:01:17 -0800

>           2 -- A certification authority's certificate, ditto

The WG already agreed that "the protocol being secured" is TLS, as the 
current draft states. TLS has exactly one certificate type: PKIX 
certificates in the format given in RFC 5280. (There is a 
non-standards-track extension to allow OpenPGP certificates.)

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 23 Feb 2011 14:20:41 -0800

On Wed, Feb 23, 2011 at 2:01 PM, Paul Hoffman <[email-masked]> wrote:
>> protocol being secured for the certificate format?
>

Right.  My suggested edit isn't meant to be a semantic change, just to
arrange that we can stop arguing about what that certificate format is
called.

... It does also mean that OpenPGP-cert extension, if it ever becomes
popular, could also be accomodated by cert types 1 and 2, because they
would still be "certificates in the wire format used by the protocol".
 Personally I see that as a good thing, because (one fervently hopes)
the OpenPGP format is unambiguously distinguishable from the X.509
format, so putting that information into the RR metadata would be a
redundancy and open the possibility of the two being out of sync.

... Come to think of it, the distinction between cert types 1 and 2
(end entity or CA) is *also* a redundancy (with the isCA field and/or
the key usage restrictions) that should perhaps be eliminated.  Why
not just use type 1 for both, and have the client's processing pay
attention to the cert's self-description?  (This is not a rhetorical
question; maybe there's a good reason I don't know about.)

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Feb 2011 17:23:58 -0500

Which is a profile of X.509 V3:

This memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this
   approach and model is provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.

It is pretty important to specify the version number since we are going to
need to revisit the format in the next 40 years as the date field was
botched.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2011 22:23:10 -0500

Scott,

Sorry my reply got stuck in my outbox for a day or so.

>existing certs out there?

I was describing constraints for a cert to be stored in the DNS,
and to be used as a CA/TA. These are newly-generated certs, and I was
addressing the arguments about the potential complexity of using X.509
certs for this purpose.

So, is the motivation here that Amazon wants to use DANE to protect itself
from rogue TAs in browsers?  An X.509 EE cert contains the name of its issuer.
The problem with trying to have the same EE cert be verified by the 
existing, browser-based TA and a TA acquired via DANE, is that they 
would need to have the same Subject name. If that name must match the 
DNS name from which the record was obtained, there is a problem :-) 
trying to convey or reference a common TA.

>updating the DNS. EEs have no control over the CA's certs.

What CA cert? A web site has an EE cert, it does mot have a CA cert
to renew (typically). Did you mean not renewing its EE cert?

>...

I don't know that ASN.1 parsing vulnerabilities are still a valid 
concern, but at least I understand your point.

>The status quo today--the world without DANE.

I now understand what the "non-DANE" cases are, but I don't 
understand your argument. The way the DANE doc reads mow, there do 
not appear to be any changes to cert parsing.

>probably better stated as "obey both".

OK.

>making the RRSIG period be short isn't so onerous as long as you can

Some folks issue very short lifetime certs already. It is not done by
CAs where the process costs $, but that would not be a requirement 
for DANE-based certs.  SO, I still think that it is a mistake to 
compare the
RSIG period with a revocation mechanism like CRLs or OCSP.

>Which works for new certs but not existing ones.

At first I thought that Rex had cited an example of Entrust using a 
v1 cert. But, upon further discussion with him I learned that what he 
was saying is that Entrust has several non-conforming v3 certs in 
some browsers, e.g., certs without a basic constraint extension or 
with such an extension, but not marked critical, etc. None of these 
bad certs have path length in them, so I think that is a red herring.

>>  that have EV certs and want to also use DANE mechanisms?

EV certs are issued on the basis of a CA having been audited, and
promising to follow certain procedures when issuing EV certs.  A web site
that wants to use DANE to issue its own CA/TA is not a valid EV cert issuer
absent such an audit.

So, only if there is a way to use DANE to point to the extant EV cert issuer
would it be reasonable to use DANE and simultaneously preserve the EV property
of an extant web site (EE) cert.

Steve