--===============0578319377668168589==
Content-Type: multipart/signed;
  boundary="nextPart2048266.nsyYnjg2fL";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2048266.nsyYnjg2fL
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Samstag 20 Januar 2024 05:55:34 schrieb Daniel Kahn Gillmor:
> >(Theoreticall if the same algorithms were used, the
> > private key material could be used in both systems, but there is no
> > technical support for this, that I would know of, so it would only be
> > a hack.)
>
> I'd go so far as to say that "no technical support for" reusing secret
> keys across protocols is a feature, not a bug.
>
> Even as a hack, it's probably a bad idea to reuse any key for two
> entirely different protocols. =20

It may or not may be. I guess that saying a "hack" means that you would be=
=20
fully your own. A bad idea unless you want to do research or playing around.

> The risk here is a "cross-protocol" attack risk

That is obvious, though, if any implementation or protocol makes a mistake=
=20
that can be used against you, when using the same secret material you doubl=
e=20
the risk.

> Say you hold a secret key Z and you have announced that you are using it
> both protocols, by making both an OpenPGP certificate that contains the
> secret key material, and an X.509 certificate that contains the secret
> key material.

I hope that both the OpenPGP pubkey and the CMS certificate will not
"contain the secret key material". ;)

> I can tell you from being involved in some parts of standardization of
> both OpenPGP and CMS that these protocols *were not* designed with such
> domain separation in mind.  Was that a mistake?  Yes, probably.=20

Or it was a good decision, if this reduces complexity in both implementatio=
ns.

GnuPG and RNP (used by Thunderbird) plan to roll out https://librepgp.org/
which they have proposed as next OpenPGP standard and aim for less complexi=
ty=20
that the proprosed crypto-refresh protocol.

Just like you I have not fully understood how much tradeoff there is between
this "domain separation" and a more easily understood implementation.
But let us not discuss the next OpenPGP Standards details here=20
on the Gpg4win-Users mailinglist, but on a mailinglist more focussed on the=
=20
cryptographic details e.g. on=20
https://lists.gnupg.org/mailman/listinfo/librepgp-discuss

Best Regards,
Bernhard
=20
=2D-=20
https://intevation.de/~bernhard =C2=A0 +49 541 33 508 3-3
Intevation GmbH, Osnabr=C3=BCck, DE; Amtsgericht Osnabr=C3=BCck, HRB 18998
Gesch=C3=A4ftsf=C3=BChrer: Frank Koormann, Bernhard Reiter

--nextPart2048266.nsyYnjg2fL
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEvdlX+cT+D9xYPc1tK3ujv5vDpVQFAmWuPGYACgkQK3ujv5vD
pVQ3iQv/dRtGZIKMFLj9vLtSzFm7oH/g5F/xgCaan1d6w64ZXs7tlH4fXI9/aur6
tM3DJ5HMgKRzDkzNAzCEy68D0UIktAuahAzPvB62PcxKtkVE7Osqb0S5IvKqaQvB
5EG8g33DMEZpRJYhHVpTSVXPzIa0VwhEyg0Su+taEHi5LX1gNRkEkPM5ZB1aQdkn
cav66JYaRERSWrAiaK/hHs5XzV5iBbICyvEWeQL3Yo7gM/YnQ95HlKhfAcj6CuV1
/Y/QVa1HZEAAsc8gRY290O87VK+sUfIsRZhN1BwQJy9dbQFrQ+T5o2UidVKRiydI
bqZmvSOf+oDiLwH6FvucqPX/whb6EEu4QiinWxw9kkI9wCae4lyapUqzuzDPtSaW
iQQRm0xTYjRuKxpVk/G/wTDiRhnuOnQzisms7CNA/CYC2i4siXc1INX51sP0a2XI
XzFN6OQM3OsSdJH8XsG0+Np4HbVGspXHmOcSbpI2gpas5qpysm/eEsxWWt3Kh2C1
DrjsjCse
=eynb
-----END PGP SIGNATURE-----

--nextPart2048266.nsyYnjg2fL--

--===============0578319377668168589==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KR3BnNHdpbi11
c2Vycy1lbiBtYWlsaW5nIGxpc3QKR3BnNHdpbi11c2Vycy1lbkB3YWxkLmludGV2YXRpb24ub3Jn
Cmh0dHBzOi8vbGlzdHMud2FsZC5pbnRldmF0aW9uLm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGlu
Zm8vZ3BnNHdpbi11c2Vycy1lbg==

--===============0578319377668168589==--