Re: [keyassure] [dane] protocol #20 (new): Change the format of

[Stephen Kent <[e-mail]>]

At 7:26 PM +0100 2/22/11, Martin Rex wrote:
>Stephen Kent wrote:
>>  >
>>  >Simplicity and robustness.
>>  >
>>  >When simple public keys for servers are to be used with DANE, these
>>  >will usually be X.509v1 certificates, which do not contain
>>  >a BasicConstraints extension.
>>
>>  Why would they be v1 certs?
>>
>>  We know that using v1 certs introduced vulnerabilities in browsers,
>>  e.g., it enabled EEs to issue subordinate certs.
>
>Getting all X.509v3 attributes into a usable consistent fashion is
>pretty difficult -- and a complete waste if they're supposed to be
>entirely ignored.

I agree, but that seems orthogonal to what I proposed, i.e., a profile
for certs that would be stored in TLSA records.

>Also self-signed X.509v3 End-Entity certs don't really exist.

I agree that if the cert is self-signed, it should, be a CA cert based
on fundamental X.509/PKIX rules, but if an SS cert is a TA package, this
is a bit less clear.

>I know that self-signed X.509v1 certs work fine with TLS implementations.
>I wouldn't know which exact attributes I would have to add to a
>self-signed X.509v3 certificate in order to not run into interop
>problems.  E.g. a KeyUsage constraint _without_ keyCertSign in an
>X.509v3 self-signed certificate would obviously be self-contradictory.

because a self-signed cert used as a TA pkg is special, it's hard to argue what
is required.

>  > I thought that browsers were fixed and that most commercial CAs used
>  > v3 certs now, since v3 has been the current standard for a very long
>>  time. I'm surprised to hear that Entrust still has a v1 cert out
>>  there
>
>That Entrust cert is a v3 cert -- which is why our software rejects it.

I (and I think some others) got the opposite impression from your 
message.  Nevermind.

>But it seems that most other PKI-Software (MS-CryptoAPI, Firefox, ...)
>did not complain about this malformed X.509v3 TrustAnchor, because they're
>shipping it as trust anchor.

I can believe that, because if you view it as a TA package, then there are
no hard and fast rules about what needs to be verified.

>  > Anyway, why should we think in terms of v1 certs for servers at this
>  > point in time? Do you statistics that suggest that most (many?) web
>>  sites are using v1 certs?  if we're talking about certs that sites
>>  can issue themselves (vs. buying certs), then there is a lot of v3
>>  cert CA SW available.
>
>selfsigned X.509v1 containers are the X.509 public key bag that
>we're looking for for TLSA EE certs -- those where NO PKIX certificate
>path validation is to be performed on the certificate.

You really can't perform path validation on an SS cert, because there 
is no path :-). The issue is what other cert validation checks one 
should perform, and what use one should make of the fields in the 
cert wrt path validation for certs that chain to it.

Steve