Skip to Content.
Sympa Menu

cacert-devel - Re: CAcert root certificates re-introduced to Debian as "ca-cacert" package

Subject: CAcert Code Development list.

List archive

Re: CAcert root certificates re-introduced to Debian as "ca-cacert" package


Chronological Thread 
  • From: Benny Baumann <benbe AT cacert.org>
  • To: Dmitry Smirnov <onlyjob AT member.fsf.org>, cacert-sysadm AT lists.cacert.org
  • Cc: Developers CAcert <cacert-devel AT lists.cacert.org>, Benedikt Heintel <benedikt AT cacert.org>
  • Subject: Re: CAcert root certificates re-introduced to Debian as "ca-cacert" package
  • Date: Mon, 25 May 2015 15:09:30 +0200

Hi,

Am 25.05.2015 um 13:50 schrieb Dmitry Smirnov:
> On Mon, 25 May 2015 12:52:18 Benny Baumann wrote:
>> wget the index.php?id=3 page and simply gpg --verify that page. Use
>> --keyring tmpfile --secret-keyring /dev/null and gpg import the public
>> key into tmpfile prior to verification.
>> Some details on temporary keyrings can be found at
>> http://superuser.com/a/450760
>>
>> Regarding DNSSEC and fingerprints (copy from mail to crit):
>> ---
>> But basically you start doing:
>> DNSDATA=$(LC_ALL=C dig +sigchase +trusted-key=/usr/share/dns/root.key
>> +topdown _sha256.root.g1._fp.cacert.org.)
>>
>> using the package dns-root-data validation. From there you check the DNS
>> query for success checking the line saying ";; FINISH : ...chain of
>> trust: SUCCESS"
>>
>> If that's the case, you filter the output for the actual TXT records and
>> cut -d/-f yourself the right slices.
>> ---
>
> Thanks for your suggestions. I'll have a look into this.
>
>
NP. Had some trouble when testing locally (no DNSSEC currently configured).

>> Regarding the actual names for those records (yet to be included in the
>> zone):
>> ---
>> I'd suggest something like:
>>
>> _certs.g1._fp.cacert.org. 86400 IN TXT "root class3"
>>
>> _url.root.g1._fp.cacert.org. 86400 IN TXT
>> "http://www.cacert.org/certs/root.crt";
>> _md5.root.g1._fp.cacert.org. 86400 IN TXT "..."
>> _sha1.root.g1._fp.cacert.org. 86400 IN TXT "..."
>> _sha256.root.g1._fp.cacert.org. 86400 IN TXT "..."
>>
>> _url.class3.g1._fp.cacert.org. 86400 IN TXT
>> "http://www.cacert.org/certs/class3.crt";
>> _md5.class3.g1._fp.cacert.org. 86400 IN TXT "..."
>> _sha1.class3.g1._fp.cacert.org. 86400 IN TXT "..."
>> _sha256.class3.g1._fp.cacert.org. 86400 IN TXT "..."
>>
>> No spaces or colons, lowercase, plain fingerprint.
>>
>> OT: The new set of roots will become available as "g2" (Generation 2).
>> ---
>> The format should be easy to access with dig +short TXT
>
> I don't really understand how/where to use the above.
>
>
Once those are installed in the DNS you can do a query for TXT records
at the described names. The records are set up so you can query the
checksum you need (e.g. SHA2-256) for the certificate you want to verify
(e.g. class3) and check the fingerprint to match the one queried. This
is secure when DNSSEC is used AND the full path is properly verified.

>>> I could include
>>> disclaimer to README.Debian file but that would be just a duplication that
>>> adds little to the usefulness of the package.
>>
>> I'm not that happy with that solution either for the same reasons you
>> mentioned. The only location where I COULD think reproduction of said
>> notice (apart from the licence file) would be (as suggested) at
>> installation time.
>
> No need to worry about this. Non interactive disclaimers are not very
> useful
> and they can be easily ignored (and interactive disclaimers are much much
> worse). Besides as systems administrator I can tell that I'm not excited to
> see the same annoying disclaimer more than once when I install the package
> to
> hundred systems. Systems administrators is not the audience to flash your
> disclaimers upon more than once and it is not possible to determine if it
> was
> already seen. Also I have a feeling that it may scare away some people
> instead
> of encouraging them to use CAcert. IMHO from any point of view there is
> more
> harm than good.
>
>
>> Well, k. I'm not quite happy, but let's leave that for now.
>
> Agreed, let's leave it.
>

Regards,
BenBE.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.18.

Top of Page