• Strategy for the upgrade of weak PGP keys?

    From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Sun Apr 5 14:04:47 2020
    XPost: news.software.nntp

    Hi all,

    Is there a current strategy to deal with weak PGP keys that are
    currently used to sign control articles and no longer accepted by recent
    GnuPG versions?

    Shouldn't news administrators still sending control articles with such
    weak PGP keys generate a new key as soon as possible and begin to send
    control articles in double during a few years? (one control article
    signed with the old key for legacy systems, and one with the new secure key)


    Most hierarchies are concerned, according to an article from
    news.software.nntp in 2015 (<n62tgi$4co$1@csiph.com> from Kevin
    Bowling). Only 15 successfully imported keys out of 104 with GnuPG 2.1 !
    One has to switch to old GnuPG 1.x versions, which one day won't be
    supported any longer...

    kev-ws-aurora% gpg --import --homedir=. PGPKEYS
    gpg: WARNING: unsafe permissions on homedir '.'
    gpg: Warning: using insecure memory!
    gpg: keybox './pubring.kbx' created
    gpg: ./trustdb.gpg: trustdb created
    gpg: key 2322A7F8: public key "usenet@aioe.org (Aioe.org Steering Group) <usenet@aioe.org>" imported
    gpg: key 7DC1A266: public key "bofh-control@lists.killfile.org" imported
    gpg: key 91EDC5F2: public key "news@dictatorshandbook.net" imported
    gpg: key C86CC6E1: public key "News Subsystem <news@ns.grisbi.org>" imported gpg: key F1420E8E: public key "news@zhaum.xs4all.nl" imported
    gpg: key ED63AD9A: public key "newsmaster@carnet.hr" imported
    gpg: key 624FADC4: public key "control@usenet.ie" imported
    gpg: key DC7DB7A7: public key "mensa.config" imported
    gpg: key E60E2FAA: public key "control-microsoft@trigofacile.com" imported
    gpg: key 9574C26C: public key "pbinfo-news-admin
    <news@uni-paderborn.de>" imported
    gpg: key 8B2ACFBB: public key "newsadmin@perl.org" imported
    gpg: key 161BD1B7: public key "news@postgresql.org" imported
    gpg: key 6933A636: public key "sfnet@cs.tut.fi" imported
    gpg: key 85854234: public key "Hirtenrat (Maintainer szaf.*) <hirtenrat@szaf.org>" imported
    gpg: key B73CAF1B: public key "us-control@lists.killfile.org" imported
    gpg: Total number processed: 104
    gpg: skipped PGP-2 keys: 89
    gpg: imported: 15


    --
    Julien ÉLIE

    « Petite annonce : Sourd rencontrerait sourde pour terrain
    d'entente. »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tristan Miller@21:1/5 to All on Wed May 20 14:15:26 2020
    XPost: news.software.nntp

    Dear Julien,

    On 05/04/2020 14.04, Julien ÉLIE wrote:
    Is there a current strategy to deal with weak PGP keys that are
    currently used to sign control articles and no longer accepted by recent GnuPG versions?

    Shouldn't news administrators still sending control articles with such
    weak PGP keys generate a new key as soon as possible and begin to send control articles in double during a few years?  (one control article
    signed with the old key for legacy systems, and one with the new secure
    key)


    Most hierarchies are concerned, according to an article from news.software.nntp in 2015 (<n62tgi$4co$1@csiph.com> from Kevin
    Bowling).  Only 15 successfully imported keys out of 104 with GnuPG 2.1 ! One has to switch to old GnuPG 1.x versions, which one day won't be
    supported any longer...

    Thanks for bringing this up. The issue is something that the recently reconstituted Big-8 Management Board has been discussing, at least
    insofar as it relates to the control messages that the Board itself
    needs to sign. But you're right that this is a more general problem.
    We're working on a solution.

    Regards,
    Tristan

    --
    Usenet Big-8 Management Board
    board@big-8.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthew Vernon@21:1/5 to Tristan Miller on Wed May 20 14:21:04 2020
    XPost: news.software.nntp

    Tristan Miller <tmiller@big-8.org> writes:

    Dear Julien,

    On 05/04/2020 14.04, Julien ÉLIE wrote:
    Is there a current strategy to deal with weak PGP keys that are
    currently used to sign control articles and no longer accepted by recent
    GnuPG versions?

    Shouldn't news administrators still sending control articles with such
    weak PGP keys generate a new key as soon as possible and begin to send
    control articles in double during a few years?  (one control article
    signed with the old key for legacy systems, and one with the new secure
    key)


    Most hierarchies are concerned, according to an article from
    news.software.nntp in 2015 (<n62tgi$4co$1@csiph.com> from Kevin
    Bowling).  Only 15 successfully imported keys out of 104 with GnuPG 2.1 ! >> One has to switch to old GnuPG 1.x versions, which one day won't be
    supported any longer...

    Thanks for bringing this up. The issue is something that the recently reconstituted Big-8 Management Board has been discussing, at least
    insofar as it relates to the control messages that the Board itself
    needs to sign. But you're right that this is a more general problem.
    We're working on a solution.

    My uk.* Control hat is worried about this too - I could make a new key
    and (probably!) adjust the perl lashup that runs uk.* to sign with both
    keys, but the real problem is getting "enough" admins to start trusting
    the new key (and not the old one any more).

    My feeling is that a co-ordinated effort to get "active" heirarchies to
    produce new keys and have them rolled out in an easy-to-consume way for
    news admins so admins don't have to do more than one or two simple
    actions is probably the only chance we have of getting a critical mass
    of servers using the new keys. B-8MB are perhaps the right people to do
    that co-ordination?

    Matthew

    --
    `O'-----0 `O'---. `O'---. `O'---.
    \___| | \___|0-/ \___|/ \___|
    | | /\ | | \ | |\ | |
    The Dangers of modern veterinary life

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tristan Miller@21:1/5 to Matthew Vernon on Wed May 20 16:45:33 2020
    XPost: news.software.nntp

    Dear Matthew,

    On 20/05/2020 15.21, Matthew Vernon wrote:
    Tristan Miller <tmiller@big-8.org> writes:
    On 05/04/2020 14.04, Julien ÉLIE wrote:
    Is there a current strategy to deal with weak PGP keys that are
    currently used to sign control articles and no longer accepted by recent >>> GnuPG versions?

    Shouldn't news administrators still sending control articles with such
    weak PGP keys generate a new key as soon as possible and begin to send
    control articles in double during a few years?  (one control article
    signed with the old key for legacy systems, and one with the new secure
    key)

    Thanks for bringing this up. The issue is something that the recently
    reconstituted Big-8 Management Board has been discussing, at least
    insofar as it relates to the control messages that the Board itself
    needs to sign. But you're right that this is a more general problem.
    We're working on a solution.

    My uk.* Control hat is worried about this too - I could make a new key
    and (probably!) adjust the perl lashup that runs uk.* to sign with both
    keys, but the real problem is getting "enough" admins to start trusting
    the new key (and not the old one any more).

    My feeling is that a co-ordinated effort to get "active" heirarchies to produce new keys and have them rolled out in an easy-to-consume way for
    news admins so admins don't have to do more than one or two simple
    actions is probably the only chance we have of getting a critical mass
    of servers using the new keys. B-8MB are perhaps the right people to do
    that co-ordination?


    We'e only recently reconstituted the Board after a long period of
    dormancy and are currently busy trying to get all the technical and administrative infrastructure back up and running. But part of this
    process has involved (and will continue to involve) getting in touch
    with news admins to verify that they're following the correct
    instructions for fetching group lists, verifying control messages, etc.
    We can't promise that we'll be able to do this on behalf of other
    hierarchies, but at the very least we can report on our experiences for
    the hierarchies that we manage.

    Regards,
    Tristan

    --
    Usenet Big-8 Management Board
    board@big-8.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Matthew Vernon on Wed May 20 11:31:26 2020
    XPost: news.software.nntp

    Matthew Vernon <control@usenet.org.uk> writes:

    My feeling is that a co-ordinated effort to get "active" heirarchies to produce new keys and have them rolled out in an easy-to-consume way for
    news admins so admins don't have to do more than one or two simple
    actions is probably the only chance we have of getting a critical mass
    of servers using the new keys. B-8MB are perhaps the right people to do
    that co-ordination?

    It would also be nice if someone with time could do a bit of a survey of supported software and key strengths and whatnot and recommend what to
    use. My guess is that everyone could just use 2048-bit RSA keys generated
    with GnuPG v2 (to pick up the current ancillary settings) and it would
    probably be fine, but is there anything in there that's going to break on
    some old system that only has GnuPG v1? (Do we even care?)

    Is anyone worried that 2048-bit RSA is not strong enough given how much of
    a pain it is to replace keys and thus how long of an expected lifetime we
    would like them to have? They're probably not quantum-safe (not that I
    really expect anyone to waste quantum computing cycles on breaking Usenet control messages). (Is there even a quantum-resistant public key
    algorithm? ed25519 isn't quantum-resistant either, I believe.)

    It would probably also be a good idea to provide a simpler mechanism to
    quickly construct a keyring of known hierarchies. I have all the
    machinery available to build such a thing, but the instructions for a news admin are a bit awkward.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam H. Kerman@21:1/5 to Tristan Miller on Wed May 20 20:09:00 2020
    XPost: news.software.nntp

    Tristan Miller <tmiller@big-8.org> wrote:

    Thanks for bringing this up. The issue is something that the recently >reconstituted Big-8 Management Board has been discussing, at least
    insofar as it relates to the control messages that the Board itself
    needs to sign. But you're right that this is a more general problem.
    We're working on a solution.

    Skirv won't be issuing control messages any longer? All that's issued is
    a cron job doing the checkgroups. I sure don't see why Skirv can't
    continue to maintain that. You really don't want to be in a position in
    which you must convince all the world's News administrators to implement
    new keys. Unless I'm missing something and Skirv isn't using stronger encryption.

    Also, you're hierarchy administrators. It's long past time to retire the pompous title that at no point described the genuine duties. Hierarchy administration isn't any kind of management function, certainly not on
    Usenet with its distributed server model and lack of central management authority.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam H. Kerman@21:1/5 to Russ Allbery on Wed May 20 20:54:30 2020
    XPost: news.software.nntp

    Russ Allbery <eagle@eyrie.org> wrote:
    "Adam H. Kerman" <ahk@chinet.com> writes:
    Tristan Miller <tmiller@big-8.org> wrote:

    Thanks for bringing this up. The issue is something that the recently >>>reconstituted Big-8 Management Board has been discussing, at least >>>insofar as it relates to the control messages that the Board itself
    needs to sign. But you're right that this is a more general problem. >>>We're working on a solution.

    Skirv won't be issuing control messages any longer?

    Tim Skirvin has never issued control messages for the Big Eight. I have
    been issuing all of the control messages since I took over from tale, and >continue to do so. . . .

    My apologies

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Adam H. Kerman on Wed May 20 13:46:33 2020
    XPost: news.software.nntp

    "Adam H. Kerman" <ahk@chinet.com> writes:
    Tristan Miller <tmiller@big-8.org> wrote:

    Thanks for bringing this up. The issue is something that the recently
    reconstituted Big-8 Management Board has been discussing, at least
    insofar as it relates to the control messages that the Board itself
    needs to sign. But you're right that this is a more general problem.
    We're working on a solution.

    Skirv won't be issuing control messages any longer?

    Tim Skirvin has never issued control messages for the Big Eight. I have
    been issuing all of the control messages since I took over from tale, and continue to do so.

    The current control messages are still being issued with the same key that David Lawrence created in 1996. At this point, that key is old enough
    that modern versions of GnuPG cannot use it. I've been meaning to deal
    with this for a long time but have had very little time (and still have
    very little time) to make many changes to the software and process.

    The most likely approach will be to generate a new key and issue control messages with both the old and new keys for some (extended) transition
    period.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Matthew Vernon on Thu May 21 09:20:12 2020
    XPost: news.software.nntp

    Matthew Vernon <control@usenet.org.uk> writes:
    My uk.* Control hat is worried about this too - I could make a new key
    and (probably!) adjust the perl lashup that runs uk.* to sign with both
    keys, but the real problem is getting "enough" admins to start trusting
    the new key (and not the old one any more).

    I’d suggest getting started quickly on dual-running for a single
    hierarchy, to discover if there are any problems with it, what the
    upgrade process looks like (given the end goal of trusting only the new
    key), etc.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Russ Allbery on Thu May 21 09:16:19 2020
    XPost: news.software.nntp

    Russ Allbery <eagle@eyrie.org> writes:
    Matthew Vernon <control@usenet.org.uk> writes:
    My feeling is that a co-ordinated effort to get "active" heirarchies
    to produce new keys and have them rolled out in an easy-to-consume
    way for news admins so admins don't have to do more than one or two
    simple actions is probably the only chance we have of getting a
    critical mass of servers using the new keys. B-8MB are perhaps the
    right people to do that co-ordination?

    It would also be nice if someone with time could do a bit of a survey of supported software and key strengths and whatnot and recommend what to
    use. My guess is that everyone could just use 2048-bit RSA keys generated with GnuPG v2 (to pick up the current ancillary settings) and it would probably be fine, but is there anything in there that's going to break on some old system that only has GnuPG v1? (Do we even care?)

    We normally target a minimum of 128-bit security which in RSA terms is a 3072-bit key. It’s probably overkill for Usenet.

    Is anyone worried that 2048-bit RSA is not strong enough given how much of
    a pain it is to replace keys and thus how long of an expected lifetime we would like them to have? They're probably not quantum-safe (not that I really expect anyone to waste quantum computing cycles on breaking Usenet control messages).

    AFAICS signed control messages include the date header. Provided news
    servers reject date headers that are distant in time, and provided
    header parsing is unambiguous, you only need to upgrade to quantum-safe signatures when you think a quantum computer actually exists, since
    stale control messages will be rejected anyway.

    (Is there even a quantum-resistant public key algorithm? ed25519
    isn't quantum-resistant either, I believe.)

    It isn’t.

    There are many candidates. Personally I would wait until the NIST PQC standardization effort completes before making a final selection (unless
    my hand was forced) but as the field narrows it would be worth keeping
    an eye on what the compromises will be, e.g. due to larger signature
    sizes than we’re used to.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Thu May 21 12:46:06 2020
    XPost: news.software.nntp

    Hi Richard,

    Is anyone worried that 2048-bit RSA is not strong enough given how much of >> a pain it is to replace keys and thus how long of an expected lifetime we
    would like them to have? They're probably not quantum-safe (not that I
    really expect anyone to waste quantum computing cycles on breaking Usenet
    control messages).

    AFAICS signed control messages include the date header. Provided news
    servers reject date headers that are distant in time, and provided
    header parsing is unambiguous, you only need to upgrade to quantum-safe signatures when you think a quantum computer actually exists, since
    stale control messages will be rejected anyway.

    That's indeed a good point. Date and Injection-Date header fields are
    expected to be signed.


    Incidentally, though it would be a huger gap, there's also the NAS
    protocol (RFC 4707) that could be used to provide information and
    updates to the list of newsgroups.
    It also gives PGP public keys, so updates are easily done through this way.
    The only PGP keys to maintain are the one of the NAS servers you trust
    to give you information.


    An experimental version is here:

    % telnet nas.trigofacile.com 991
    HELP
    HIER uk
    LSTR uk



    DATA uk.net.news.announce
    612 Information follows for newsgroups
    Name: uk.net.news.announce
    Status: Moderated
    Description: For RFDs, CFVs, FAQs, etc. within the UK Hierarchy. (Moderated) Mod-Sub-Adr: uk-net-news-announce@moderators.isc.org

    .


    HIER uk
    611 Information follows for hierarchies
    Name: uk
    Status: Complete
    Description: United Kingdom of Great Britain and Northern Ireland
    Ctl-Send-Adr: control@usenet.org.uk
    Ctl-Newsgroup: uk.net.news.announce
    Language: en
    Name-Length: 40
    Comp-Length: 19
    Source: http://www.usenet.org.uk/
    Ctl-PGP-Key:
    U uk.net.news.announce
    L http://www.usenet.org.uk/newsadmins.html
    V PGPfreeware 5.0i for non-commercial use
    K------BEGIN PGP PUBLIC KEY BLOCK-----
    K-Version: PGPfreeware 5.0i for non-commercial use
    K-
    K-mQCNAjGL0cgAAAEEAJ6p7fQHn139U9zQawLixrExOUrkFhi1yLb8m8fLxmKTprKn K-ZNM1nnxMSbRyO8vXohXKKs4G1U2jTpaCkSRrbCiJ5VxWB/B31E/p/vrBXqqQ2amq K-3gb4Df9DZub0ZtOhHTF/pPjQmXvAv08umjZWpYlXRmUHBlBhMmOfGXkh8vHZAAUR K-tBR1ay5uZXQubmV3cy5hbm5vdW5jZYkAlQMFEDhCcUxjnxl5IfLx2QEB6e8EAJDt K-gIkNXdLiyL07lgDBr+Wq/Zckgm70JhNaHWxLPqckMLOJZGPFKlOlKA6W62UrwDWI K-yktEosLHd8whbPCaMOSbIOX7mmTrIySOKf+rBxhFLlRY+fAQ4h2oEyEWYhJ80wiN K-GgKgMJC+UqQD/ylMB1VcCsTYuZWEQ18ldKgtTsOZtBc8Y29udHJvbEB1c2VuZXQu K-b3JnLnVrPokAlQIFEDGL1R1jnxl5IfLx2QEBF/gD/ikHjpmJuG10X3PXA/yciZ0r K-qqVo01/4q5yy8vHBGGfopfxpqrjGnNtUV4kWluNo0/1uYZm1o7TeqHI6Siv/yWQp K-+QldN4nED3RPauqCtj5cubmMgryXg2pcCBiY+brHWEr0tBV7cSSOHFipwM55FA22 K-ctQzQ5nIPZQ+KPC3WjdZiQB8AwUQMvCcUq1e6k0sFfGpAQE6nwMzBdaFclXiv48C K-aMXBUG8S3bLUtx3u2OBajzpe8G2nJlCKYkCY482p2MjtfCDi7+eYDfqgKMDoGrUM K-zSfMraDRyoXjNC/nIKf1+R2EFMyaLoC9FWggCKTov/I/2BE2+grvQ7ewQSWEUokA K-lQIFEDGL1FGemw5PLx059QEBje0EAKx99yOZ0zQ9FjibuEBStP8t0BCsRNqkrVjx K-O513RBXecgcdXdv9hWn+8LNRZx6JLHv/ZpWsdGXqP3oiqj+LRt7WpHnZ55He/njx K-5DAoPAM/TjgTk7arazSjsJuFhcTP7gHitLDoHxVkUfdLX8h4HH9LWhEnrWEx82EY K-/29z/xQ6iQCVAgUQMYvTeKSiIc7jUXyJAQHLNwP/Qz+g2RRsuSZrJ9L0HAVPLcml K-oAEGOMFfYJDM/mvxegAYzL8i0HGFbwTH/+E94WSmsWAx1KZ/Z2DYKdI7BUaS8c09 K-a2OtqOEbCd7QBI37seyxG0rTWNpuE0ZXBo0eiQBg37oIW+Faf/tqJQZnALVsV5LD K-Kcf+6+MhgS47HWJ6ZjQ=
    K-=iInx
    K -----END PGP PUBLIC KEY BLOCK-----

    .


    --
    Julien ÉLIE

    « Quand je raconterai mon odyssée, personne ne me croira ! »
    (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to iulius@nom-de-mon-site.com.invalid on Thu May 21 14:37:33 2020
    XPost: news.software.nntp

    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:
    Incidentally, though it would be a huger gap, there's also the NAS
    protocol (RFC 4707) that could be used to provide information and
    updates to the list of newsgroups.
    It also gives PGP public keys, so updates are easily done through this way. The only PGP keys to maintain are the one of the NAS servers you trust
    to give you information.

    Does it offer more than adding a signature PGPKEYS.asc alongside (say) ftp.isc.org/pub/pgpcontrol/PGPKEYS and verifying that as part of buildinnkeyring? I’m not convinced that introducing an entire new
    protocol into the mix is a good approach if much simpler alternatives
    are available; one of the things that’s become very clear as I bring my collection of peers back up to a sensible number is that server
    operators have very little spare time for Usenet today.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Thu May 21 20:09:21 2020
    XPost: news.software.nntp

    Hi Russ,

    AFAICS signed control messages include the date header. Provided news
    servers reject date headers that are distant in time, and provided
    header parsing is unambiguous, you only need to upgrade to quantum-safe
    signatures when you think a quantum computer actually exists, since
    stale control messages will be rejected anyway.

    Right, but my point is that this forces another key upgrade. There's a reason why it's been 24 years since we changed the key. :) But it
    doesn't sound like there's a good way to anticipate that, so we're stuck
    with it anyway.

    What about a new control message type that serves to update the public
    PGP key?
    Still maintained news servers could implement that new feature for their
    next release.

    As far as I see, if a private key is compromised, it does not change
    much between modifying the key and issuing control messages with that
    new key, and directly issuing control messages with the compromised key.
    Am I missing something?

    --
    Julien ÉLIE

    « Quand je raconterai mon odyssée, personne ne me croira ! »
    (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Richard Kettlewell on Thu May 21 10:29:37 2020
    XPost: news.software.nntp

    Richard Kettlewell <invalid@invalid.invalid> writes:

    We normally target a minimum of 128-bit security which in RSA terms is a 3072-bit key. It’s probably overkill for Usenet.

    We could just go to 4096 bits. It's not like the speed difference matters
    for Usenet. The signature length is a bit longer, but meh.

    I'd rather use ed25519, but I think that has more backwards compatibility challenges.

    Is anyone worried that 2048-bit RSA is not strong enough given how much
    of a pain it is to replace keys and thus how long of an expected
    lifetime we would like them to have? They're probably not quantum-safe
    (not that I really expect anyone to waste quantum computing cycles on
    breaking Usenet control messages).

    AFAICS signed control messages include the date header. Provided news
    servers reject date headers that are distant in time, and provided
    header parsing is unambiguous, you only need to upgrade to quantum-safe signatures when you think a quantum computer actually exists, since
    stale control messages will be rejected anyway.

    Right, but my point is that this forces another key upgrade. There's a
    reason why it's been 24 years since we changed the key. :) But it
    doesn't sound like there's a good way to anticipate that, so we're stuck
    with it anyway.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam H. Kerman@21:1/5 to Julien on Thu May 21 18:37:46 2020
    XPost: news.software.nntp

    Julien <iulius@nom-de-mon-site.com.invalid> wrote:

    . . .

    What about a new control message type that serves to update the public
    PGP key?

    Good heavens.

    I don't see how you can safely get around manual intervention.

    . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Fri May 22 08:02:07 2020
    XPost: news.software.nntp

    Hi Adam,

    What about a new control message type that serves to update the public
    PGP key?

    Good heavens.

    I don't see how you can safely get around manual intervention.

    Well, I was under the assumption that once you trusted once uk.* for
    instance (manually adding its public PGP key), renewals of the same UID
    used for control messages could be automated as long as the news user
    can update the list of PGP keys it trusts.

    If that idea is bad, OK, that was just an idea to share for an in-band
    update.

    --
    Julien ÉLIE

    « C'est une souricière, ils sont faits comme des rats ! »
    (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Fri May 22 10:20:41 2020
    XPost: news.software.nntp

    Hi Richard,

    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:
    Incidentally, though it would be a huger gap, there's also the NAS
    protocol (RFC 4707) that could be used to provide information and
    updates to the list of newsgroups.
    It also gives PGP public keys, so updates are easily done through this way. >> The only PGP keys to maintain are the one of the NAS servers you trust
    to give you information.

    Does it offer more than adding a signature PGPKEYS.asc alongside (say) ftp.isc.org/pub/pgpcontrol/PGPKEYS and verifying that as part of buildinnkeyring?

    For just an update of PGP keys, yes, using PGPKEYS would be enough.

    To update PGP keys of Big-8 and uk.* only (for instance if one only
    trusts these two hierarchy administrators):

    wget 'http://usenet.trigofacile.com/hierarchies/index.py?see=COMP,UK&only=pgpkeys' -O downloaded-keys

    The "downloaded-keys" file will contain the substract of PGPKEYS the
    news admin is interested in.

    Properly signing and checking the result, like the whole PGPKEYS file
    (with PGPKEYS.asc like you suggest), is of course needed for security.
    Put that into for instance a weekly crontab, and that's it.



    With GPG 2.1.8, only 15 keys out of 103 in PGPKEYS are imported.
    Anyway, there are far less than 103 active hierarchies nowadays.

    @Paolo, it seems that the PGP key of aioe.* has expired:

    pub dsa1024 2007-09-17 [SC] [expirée : 2010-09-16]
    22031AAC51E7C7FD664F1D8090DF6C712322A7F8
    uid [ expirée ] usenet@aioe.org (Aioe.org Steering Group) <usenet@aioe.org>


    --
    Julien ÉLIE

    « Give laugh to all but smile to one,
    Give cheeks to all but lips to one,
    Give love to all but Heart to one,
    Let everybody love you
    But you love one. »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aioe@21:1/5 to All on Fri May 22 20:09:24 2020
    XPost: news.software.nntp

    Il Fri, 22 May 2020 10:20:41 +0200, Julien ÉLIE ha scritto:


    @Paolo, it seems that the PGP key of aioe.* has expired:

    yes, i know.

    Many years ago, around 2005, i bought a dedicated server and a backup
    service from an (italian) provider who had just started the business that offered very affordable prices to its first customers. The contract
    stipulated that the price would remain the same forever.

    Four years later, my server and backup service were suddenly shut down for
    no reason and without warning.

    In everyday life, i am a lawyer and so i sued them and i got a lavish compensation from them on condition that the terms of the agreement
    remained confidential. At the same time they refused to give me back the
    disk images of the server and the contents of the backup. They preferred
    to pay a great deal of compensation than to give me the data back.

    I suppose they did this to prevent me from realizing that i had been
    cheated by them. The price was too cheap to be true, the characteristics
    of the service did not seem those foreseen by the contract even if i
    didn't care about this because the price was so cheap that i was fine.
    Criminal law is the largest part of my job, if they had been convicted of
    fraud they would have closed their firm.

    At that time, i kept the private key of the aioe.* hierarchy only on the
    server disks and in the backup and i lost both.
    I was very stupid to do this but i did not imagine that the provider
    could behave in bad faith against me.

    So at this point i can't renew the key because i can't sign the new one
    with the old one.

    I have never asked for an exception to the rule because i am ashamed of
    being such an idiot. But i was a kid, i'm a hobbyist, i never needed to
    create other groups after that time.

    If there's a workaround, i'm happy to renew my key.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Sun May 24 08:51:54 2020
    XPost: news.software.nntp

    Hi Paolo,

    @Paolo, it seems that the PGP key of aioe.* has expired

    [...]

    At that time, i kept the private key of the aioe.* hierarchy only on the server disks and in the backup and i lost both.

    So at this point i can't renew the key because i can't sign the new one
    with the old one.

    Thanks for the long explanation, that's pretty clear!
    As the old key is no longer available, it is not useful to keep it. Why
    not just ask for an update to a new key? May be worthwhile to do that
    in case you have a change in your hierarchy in a few months or weeks.
    At least people may get a chance to have your new key already installed.
    Same thing for NoCeM.

    Incidentally:
    https://news.aioe.org/documentation/aioe-technical-data/
    Links in that page lead to 404 errors (checkgroup.txt, aioe.txt,
    control.ctl).

    --
    Julien ÉLIE

    « Give laugh to all but smile to one,
    Give cheeks to all but lips to one,
    Give love to all but Heart to one,
    Let everybody love you
    But you love one. »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Hochstein@21:1/5 to Russ Allbery on Sun May 31 23:05:27 2020
    XPost: news.software.nntp

    Russ Allbery wrote:

    The current control messages are still being issued with the same key that David Lawrence created in 1996. At this point, that key is old enough
    that modern versions of GnuPG cannot use it.

    Yes, we've got the same problem (with a key from the same year :)).

    The most likely approach will be to generate a new key and issue control messages with both the old and new keys for some (extended) transition period.

    That was my first idea, too. AFAIS it's not possible to sign one
    message with different keys.

    I was hoping someone else would have time to go ahead, choose a
    sensible new key format and try it ...

    -thh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From D. Stussy@21:1/5 to All on Fri Jun 19 23:15:57 2020
    XPost: news.software.nntp

    "Julien ÉLIE" wrote in message news:r6chgv$dam$1@news.trigofacile.com...
    Is there a current strategy to deal with weak PGP keys that are
    currently used to sign control articles and no longer accepted by recent
    GnuPG versions?

    Shouldn't news administrators still sending control articles with such
    weak PGP keys generate a new key as soon as possible and begin to send
    control articles in double during a few years? (one control article
    signed with the old key for legacy systems, and one with the new secure key)


    Most hierarchies are concerned, according to an article from
    news.software.nntp in 2015 (<n62tgi$4co$1@csiph.com> from Kevin
    Bowling). Only 15 successfully imported keys out of 104 with GnuPG 2.1 !
    One has to switch to old GnuPG 1.x versions, which one day won't be
    supported any longer...

    kev-ws-aurora% gpg --import --homedir=. PGPKEYS
    gpg: WARNING: unsafe permissions on homedir '.'
    gpg: Warning: using insecure memory!
    gpg: keybox './pubring.kbx' created
    gpg: ./trustdb.gpg: trustdb created
    gpg: key 2322A7F8: public key "usenet@aioe.org (Aioe.org Steering Group) <usenet@aioe.org>" imported
    gpg: key 7DC1A266: public key "bofh-control@lists.killfile.org" imported
    gpg: key 91EDC5F2: public key "news@dictatorshandbook.net" imported
    gpg: key C86CC6E1: public key "News Subsystem <news@ns.grisbi.org>" imported gpg: key F1420E8E: public key "news@zhaum.xs4all.nl" imported
    gpg: key ED63AD9A: public key "newsmaster@carnet.hr" imported
    gpg: key 624FADC4: public key "control@usenet.ie" imported
    gpg: key DC7DB7A7: public key "mensa.config" imported
    gpg: key E60E2FAA: public key "control-microsoft@trigofacile.com" imported
    gpg: key 9574C26C: public key "pbinfo-news-admin
    <news@uni-paderborn.de>" imported
    gpg: key 8B2ACFBB: public key "newsadmin@perl.org" imported
    gpg: key 161BD1B7: public key "news@postgresql.org" imported
    gpg: key 6933A636: public key "sfnet@cs.tut.fi" imported
    gpg: key 85854234: public key "Hirtenrat (Maintainer szaf.*) <hirtenrat@szaf.org>" imported
    gpg: key B73CAF1B: public key "us-control@lists.killfile.org" imported
    gpg: Total number processed: 104
    gpg: skipped PGP-2 keys: 89
    gpg: imported: 15
    ============
    I get a similar result. I run a cron job once per week to update keys against the public key servers. What they should do is
    update the keys on the public servers at least a week before intended use.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Russ Allbery on Sat Aug 22 17:23:25 2020
    XPost: news.software.nntp

    Russ Allbery <eagle@eyrie.org> writes:

    The current control messages are still being issued with the same key
    that David Lawrence created in 1996. At this point, that key is old
    enough that modern versions of GnuPG cannot use it. I've been meaning
    to deal with this for a long time but have had very little time (and
    still have very little time) to make many changes to the software and process.

    The most likely approach will be to generate a new key and issue control messages with both the old and new keys for some (extended) transition period.

    As a quick update on this, I've been working on wrangling PGP::Sign into
    shape, since all the rest of my machinery depends on it. That's mostly
    done, although I have to sort out some more test failures. It now
    supports using GnuPG v2 to create and validate signatures.

    Once I get the rest of the test issues sorted out, the next step is to
    create a new test key for the Big Eight and start dual-issuing control messages. I'll do that for a while and let people test (and find any
    problems with the key that might require recreating it) before officially changing the key.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jason Evans@21:1/5 to Russ Allbery on Sun Aug 23 15:37:41 2020
    XPost: news.software.nntp

    On Sat, 22 Aug 2020 17:23:25 -0700, Russ Allbery wrote:

    Russ Allbery <eagle@eyrie.org> writes:

    Once I get the rest of the test issues sorted out, the next step is to
    create a new test key for the Big Eight and start dual-issuing control messages. I'll do that for a while and let people test (and find any problems with the key that might require recreating it) before
    officially changing the key.

    Thanks for working on this, Russ. We really appreciate it!

    Jason

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthew Vernon@21:1/5 to Russ Allbery on Wed Aug 26 17:35:57 2020
    XPost: news.software.nntp

    Russ Allbery <eagle@eyrie.org> writes:

    Once I get the rest of the test issues sorted out, the next step is to
    create a new test key for the Big Eight and start dual-issuing control messages. I'll do that for a while and let people test (and find any problems with the key that might require recreating it) before officially changing the key.

    Do you have a plan for getting news server operators to deploy the new
    key? If so, could we potentially piggy-back other heirarchies into that process?

    Matthew
    [one of my hats is uk.* Control]
    --
    `O'-----0 `O'---. `O'---. `O'---.
    \___| | \___|0-/ \___|/ \___|
    | | /\ | | \ | |\ | |
    The Dangers of modern veterinary life

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Matthew Vernon on Wed Aug 26 10:26:52 2020
    XPost: news.software.nntp

    Matthew Vernon <matthew@debian.org> writes:
    Russ Allbery <eagle@eyrie.org> writes:

    Once I get the rest of the test issues sorted out, the next step is to
    create a new test key for the Big Eight and start dual-issuing control
    messages. I'll do that for a while and let people test (and find any
    problems with the key that might require recreating it) before
    officially changing the key.

    Do you have a plan for getting news server operators to deploy the new
    key? If so, could we potentially piggy-back other heirarchies into that process?

    I don't, other than updating the key on ftp.isc.org and making an
    announcement to news.admin.announce (and presumably the Big Eight Board
    will want to make an announcement to news.announce.newgroups).

    I expect to have to keep issuing the control messages with the old key for years. I'll probably keep doing it until Debian drops GnuPG v1 from the archive.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Sat Oct 10 12:45:46 2020
    XPost: news.software.nntp

    Hi Russ,
    The most likely approach will be to generate a new key and issue control
    messages with both the old and new keys for some (extended) transition
    period.

    As a quick update on this, I've been working on wrangling PGP::Sign into shape, since all the rest of my machinery depends on it. That's mostly
    done, although I have to sort out some more test failures. It now
    supports using GnuPG v2 to create and validate signatures.

    Once I get the rest of the test issues sorted out, the next step is to
    create a new test key for the Big Eight and start dual-issuing control messages. I'll do that for a while and let people test (and find any problems with the key that might require recreating it) before officially changing the key.

    We plan on doing a similar move for the PGP key used to sign control
    messages for the fr.* hierarchy. Maybe we could synch our efforts and
    choose a similar algorithm for the Big-Eight and fr.* hierarchies?

    An EdDSA algorithm like ed25519 [RFC8032]?
    Debian has been shipped with an OpenSSH version implementing ed25519
    since Jessie (2015). Jessie was also the last version to come with
    GnuPG 1.4; Strech has 2.1.

    So it seems to be a good choice for the transition between old and new
    keys for interoperability.

    --
    Julien ÉLIE

    « Je suis adroit de la main gauche et je suis gauche de la main
    droite. » (Raymond Devos)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Sat Nov 14 13:53:20 2020
    XPost: news.software.nntp

    Hi all,

    The most likely approach will be to generate a new key and issue control >>> messages with both the old and new keys for some (extended) transition
    period.
    [...]
    We plan on doing a similar move for the PGP key used to sign control
    messages for the fr.* hierarchy.  Maybe we could synch our efforts and choose a similar algorithm for the Big-Eight and fr.* hierarchies?

    An EdDSA algorithm like ed25519 [RFC8032]?
    Debian has been shipped with an OpenSSH version implementing ed25519
    since Jessie (2015).  Jessie was also the last version to come with
    GnuPG 1.4; Strech has 2.1.

    We'll start soon the experiment for the fr.* hierarchy.
    Probably with an ed25519 key (which has a fixed 256-bit size).
    I read that difficulty to breaking it is similar to a ~3072-bit RSA key.

    Do you think it is better to change the user ID of the key or re-use the
    one of the previous old key?
    I would tend to re-use the previous user ID.

    --
    Julien ÉLIE

    « – À la plage ? Mais il pleut !
    – Pas du tout ! Dans le midi de la Gaule, il pleut. Ici, c'est tout
    juste un peu humide. Vivifiant. Pas vrai, Astérix ?
    – Ce matin, ça devient de plus en plus vivifiant ! » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthew Vernon@21:1/5 to iulius@nom-de-mon-site.com.invalid on Mon Nov 16 10:53:49 2020
    XPost: news.software.nntp

    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

    We'll start soon the experiment for the fr.* hierarchy.
    Probably with an ed25519 key (which has a fixed 256-bit size).
    I read that difficulty to breaking it is similar to a ~3072-bit RSA key.

    My concern here is that we have to use an old gpgv (so that it
    understand the old keys) to verify control messages at the moment, and
    it won't understand very modern keys. Which is going to make migration a
    pain in a number of ways (e.g. my current ancient tooling for signing
    control messages uses gpg1 because modern gpg refuses to use the old
    uk.* key - so if I make a new key I have to use a new toolchain with
    that).

    Do you think it is better to change the user ID of the key or re-use
    the one of the previous old key?
    I would tend to re-use the previous user ID.

    I would definitely favour using the old key ID - e.g. I have control.ctl
    set to verify control@usenet-fr.news.eu.org for fr.* so (assuming
    previous questions about toolchain can be finessed) if your new key has
    the same ID I won't have to change control.ctl at all.

    Matthew

    --
    `O'-----0 `O'---. `O'---. `O'---.
    \___| | \___|0-/ \___|/ \___|
    | | /\ | | \ | |\ | |
    The Dangers of modern veterinary life

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Mon Nov 16 12:21:31 2020
    XPost: news.software.nntp

    Hi Matthew,

    We'll start soon the experiment for the fr.* hierarchy.
    Probably with an ed25519 key (which has a fixed 256-bit size).
    I read that difficulty to breaking it is similar to a ~3072-bit RSA key.

    My concern here is that we have to use an old gpgv (so that it
    understand the old keys) to verify control messages at the moment, and
    it won't understand very modern keys. Which is going to make migration a
    pain in a number of ways (e.g. my current ancient tooling for signing
    control messages uses gpg1 because modern gpg refuses to use the old
    uk.* key - so if I make a new key I have to use a new toolchain with
    that).

    The plan is to send control articles in double, during a few years.
    One signed with the old key (supported by gpgv1 or equivalent, and
    earlier versions of gpgv2), and another one signed with a modern key
    (supported by modern gpgv2).

    This way, news servers can cope with hierarchy updates, and can migrate
    from gpgv1 to gpgv2 when they want to verify control messages. A smooth transition.
    Wouldn't it suit you needs? (gpgv1 / gpgv2)


    As for tooling for signing control messages, yes, both toolchains have
    to be maintained by hierarchy administrators. We're not plenty...




    Do you think it is better to change the user ID of the key or re-use
    the one of the previous old key?
    I would tend to re-use the previous user ID.

    I would definitely favour using the old key ID - e.g. I have control.ctl
    set to verify control@usenet-fr.news.eu.org for fr.* so (assuming
    previous questions about toolchain can be finessed) if your new key has
    the same ID I won't have to change control.ctl at all.

    Yes, exactly, no changes are needed to control.ctl when re-using the
    user ID.

    --
    Julien ÉLIE

    « Ma parole… Vous êtes soûls ! Heu ! Sourds… » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to iulius@nom-de-mon-site.com.invalid on Mon Nov 16 12:24:31 2020
    XPost: news.software.nntp

    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

    We plan on doing a similar move for the PGP key used to sign control
    messages for the fr.* hierarchy. Maybe we could synch our efforts and
    choose a similar algorithm for the Big-Eight and fr.* hierarchies?

    An EdDSA algorithm like ed25519 [RFC8032]? Debian has been shipped with
    an OpenSSH version implementing ed25519 since Jessie (2015). Jessie was
    also the last version to come with GnuPG 1.4; Strech has 2.1.

    I'm not currently seeing much point in using elliptic curve algorithms
    instead of RSA. They're both vulnerable to quantum cryptography, so
    there's not much in the way of future-proofing, and the security seems to
    be roughly on par. I was planning on generating a 4096-bit RSA key
    because everything understands it and has for eons, and I'm not sure how
    old of software people might be running.

    (4096 is probably overkill and 3072 would be fine.)

    The downside of RSA compared to ed25519 is that the signature is larger
    and (particularly for 4096-bit keys) slower to generate and verify, but
    given the miniscule traffic of Usenet control messages, I don't think
    there's much reason to care.

    That said, maybe I'm missing something?

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Mon Nov 16 23:16:14 2020
    XPost: news.software.nntp

    Hi Russ,
    An EdDSA algorithm like ed25519 [RFC8032]? Debian has been shipped with
    an OpenSSH version implementing ed25519 since Jessie (2015). >
    I'm not currently seeing much point in using elliptic curve algorithms instead of RSA. They're both vulnerable to quantum cryptography, so
    there's not much in the way of future-proofing, and the security seems to
    be roughly on par. I was planning on generating a 4096-bit RSA key
    because everything understands it and has for eons, and I'm not sure how
    old of software people might be running.

    (4096 is probably overkill and 3072 would be fine.)

    A 4096-bit RSA key will last longer; 3072-bit RSA keys will probably be considered weak within ten years. Same thing for ed25519 (256 bits)
    anyway... Unless using 512-bit elliptic curves.


    The downside of RSA compared to ed25519 is that the signature is larger
    and (particularly for 4096-bit keys) slower to generate and verify, but
    given the miniscule traffic of Usenet control messages, I don't think
    there's much reason to care.

    Sure!

    The question is probably more important for pgpmoose and NoCeM. Yet,
    traffic is not that high either.

    For compatibility reasons in 2020, using widespread RSA algorithm is
    probably the best. So 3072 or 4096-bit is the question.

    --
    Julien ÉLIE

    « Je suis capable du meilleur comme du pire, mais pour le pire, c'est
    moi le meilleur. » (Coluche)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Franck@21:1/5 to All on Wed Nov 18 13:57:14 2020
    XPost: news.software.nntp

    Le 16/11/2020 à 23:16, Julien ÉLIE a écrit :

    For compatibility reasons in 2020, using widespread RSA algorithm is
    probably the best.  So 3072 or 4096-bit is the question.

    I delayed the implementation for processing control messages with PGP,
    hoping that the choice would be made for RSA...

    So +1 for RSA :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Fri Nov 20 22:49:13 2020
    XPost: news.software.nntp

    Hi Franck,

    I delayed the implementation for processing control messages with PGP,
    hoping that the choice would be made for RSA...

    So +1 for RSA :-)

    There is no obligation for a hierarchy administrator to choose this
    algorithm, so a recent implementation should not implement only this one
    I believe...


    Incidentally, maybe a note about a preference for RSA keys should be
    added to https://www.eyrie.org/~eagle/faqs/usenet-hier.html (Usenet
    Hierarchy Administration FAQ)?
    Its current wording is a bit confusing, speaking about old RSA
    implementation of PGP 2.x instead of modern RSA implementations.


    "Most Usenet news sites that honor control messages are set up to verify messages signed with an algorithm called RSA, which was the algorithm
    used by the original PGP implementation. Unfortunately, this is now
    fairly obsolete. Current PGP implementations use a newer, more secure
    algorithm for generating signatures (although the additional security is probably overkill for Usenet control messages, at least for right now).
    While this doesn't pose a problem for signing messages (current PGP implementations can still use old RSA keys to sign things), it does
    cause problems if you're starting fresh, since the keys generated by
    current implementations will not work with old versions of PGP.

    What all this means is that you have a few hard choices when it comes to choosing a PGP implementation and generating your initial key pair. You
    can use GnuPG <http://www.gnupg.org/>, which is probably the best
    available PGP implementation, and not bother with a RSA key at all."

    --
    Julien ÉLIE

    « Je n'aime pas faire du char-stop ! » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Fri Nov 20 22:52:35 2020
    XPost: news.software.nntp

    Hi Russ,
    We plan on doing a similar move for the PGP key used to sign control
    messages for the fr.* hierarchy. Maybe we could synch our efforts and
    choose a similar algorithm for the Big-Eight and fr.* hierarchies?

    An EdDSA algorithm like ed25519 [RFC8032]? Debian has been shipped with
    an OpenSSH version implementing ed25519 since Jessie (2015). Jessie was
    also the last version to come with GnuPG 1.4; Strech has 2.1.

    I'm not currently seeing much point in using elliptic curve algorithms instead of RSA.

    From GnuPG FAQ:
    https://www.gnupg.org/faq/gnupg-faq.html

    %%%
    Will GnuPG ever support RSA-3072 or RSA-4096 by default?

    Probably not. The future is elliptical-curve cryptography, which will
    bring a level of safety comparable to RSA-16384. Every minute we spend
    arguing about whether we should change the defaults to RSA-3072 or more
    is one minute the shift to ECC is delayed.
    Frankly, we think ECC is a really good idea and we’d like to see it
    deployed as soon as humanly possible.
    %%%

    :)

    --
    Julien ÉLIE

    « – Le bureau des renseignements ?
    – Sais pas. Adressez-vous aux renseignements, ils vous
    renseigneront. » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to iulius@nom-de-mon-site.com.invalid on Fri Nov 20 15:02:01 2020
    XPost: news.software.nntp

    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

    From GnuPG FAQ:
    https://www.gnupg.org/faq/gnupg-faq.html

    %%%
    Will GnuPG ever support RSA-3072 or RSA-4096 by default?

    Probably not. The future is elliptical-curve cryptography, which will
    bring a level of safety comparable to RSA-16384. Every minute we spend arguing about whether we should change the defaults to RSA-3072 or more is one minute the shift to ECC is delayed.
    Frankly, we think ECC is a really good idea and we’d like to see it deployed as soon as humanly possible.
    %%%

    They subsequently changed the default to 3072-bit RSA.

    I admit that I am still feeling burned about choosing a DSA/El Gamal key
    way back in the day because of similar sorts of arguments that it was the future, when I could have created an RSA key, only to have it be
    discarded, now considered not sufficiently secure, and (longer) RSA keys continue to be the standard.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Tue Dec 8 20:55:06 2020
    XPost: news.software.nntp

    Hi Richard,

    I’d suggest getting started quickly on dual-running for a single
    hierarchy, to discover if there are any problems with it, what the
    upgrade process looks like (given the end goal of trusting only the new
    key), etc.

    Well, then let's go for the international French-speaking hierarchy
    (fr.*). Starting from January 2021, we'll be issuing control messages
    signed with a brand new PGP key.
    No dual-running, unfortunately, because we no longer have the previous
    key (but if by any chance it is found later, I'll of course be happy to
    also send control articles signed with it).


    As for the upgrade process:

    % su news
    % wget http://www.usenet-fr.net/pgp-fr-2020.txt
    % gpg --import pgp-fr-2020.txt

    works fine :-)
    At least, with INN.

    Both the old and the new key can co-exist. I've tested to verify an old control article, and a new one with the new key; both of them are
    correctly recognized.

    It's now up to news administrators to take a bit of their time to do that...

    --
    Julien ÉLIE

    « J'oubliais qu'Assurancetourix a une nouvelle corde à sa harpe ! »
    (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Tue Dec 8 21:00:08 2020
    XPost: news.software.nntp

    Hi Franck,

    For compatibility reasons in 2020, using widespread RSA algorithm is
    probably the best.  So 3072 or 4096-bit is the question.

    I delayed the implementation for processing control messages with PGP,
    hoping that the choice would be made for RSA...

    So +1 for RSA :-)

    Now that we know that the previous private key for fr.* has been lost,
    it is no longer a question... We'll go for RSA because we cannot assume
    every news server is no older than 5 years old!
    Modern algorithms cannot be chosen for us; otherwise "old" news servers
    would not been able to update their key ring without also updating GnuPG
    or like.

    --
    Julien ÉLIE

    « J'oubliais qu'Assurancetourix a une nouvelle corde à sa harpe ! »
    (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Franck@21:1/5 to All on Fri Dec 11 06:51:35 2020
    XPost: news.software.nntp

    Le 08/12/2020 à 21:00, Julien ÉLIE a écrit :

    Hi Julien,

    Now that we know that the previous private key for fr.* has been lost,
    it is no longer a question...  We'll go for RSA because we cannot assume every news server is no older than 5 years old!
    Modern algorithms cannot be chosen for us; otherwise "old" news servers
    would not been able to update their key ring without also updating GnuPG
    or like.

    I'll take a look at it as soon as I have some free time :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthew Vernon@21:1/5 to iulius@nom-de-mon-site.com.invalid on Mon Dec 14 16:32:18 2020
    XPost: news.software.nntp

    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

    % wget http://www.usenet-fr.net/pgp-fr-2020.txt

    Not https? :(

    Matthew

    --
    `O'-----0 `O'---. `O'---. `O'---.
    \___| | \___|0-/ \___|/ \___|
    | | /\ | | \ | |\ | |
    The Dangers of modern veterinary life

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Adam H. Kerman on Mon Dec 14 09:59:14 2020
    XPost: news.software.nntp

    "Adam H. Kerman" <ahk@chinet.com> writes:
    Matthew Vernon <matthew@debian.org> wrote:
    Julien ELIE <iulius@nom-de-mon-site.com.invalid> writes:

    % wget http://www.usenet-fr.net/pgp-fr-2020.txt

    Not https? :(

    As you're not logging on, why would you care? There is no security implication.

    If the network between the request and www.usenet-fr.net is insecure in
    some way (DNS, network interception, etc.), an adversary can substitute
    their own key in the response and then issue control messages with the adversary's key that would be effective for fr.* at that site.

    I don't think anyone is likely to bother to go to this effort for Usenet control messages, but it does weaken the chain of trust for the key that
    you retrieve from that web request to not use TLS.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    Please post questions rather than mailing me directly.
    <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam H. Kerman@21:1/5 to Matthew Vernon on Mon Dec 14 17:48:46 2020
    XPost: news.software.nntp

    Matthew Vernon <matthew@debian.org> wrote:
    Julien ELIE <iulius@nom-de-mon-site.com.invalid> writes:

    % wget http://www.usenet-fr.net/pgp-fr-2020.txt

    Not https? :(

    As you're not logging on, why would you care? There is no security
    implication.

    A friend of mine explained why Google pushed for https, when I was,
    well, intimidated into using https for each of my domains. My Web pages
    are ugly text-only informational pages. There's nothing to log in for.

    ISPs had begun substituting advertising from their own clients for that
    of Google's advertising clients. https on non-interactive Web sites is
    an attempt to thwart that.

    There are no security implications for either the Webmaster nor user at
    issue here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Tue Dec 15 19:41:59 2020
    XPost: news.software.nntp

    Hi Matthew,
    % wget http://www.usenet-fr.net/pgp-fr-2020.txt

    Not https? :(

    I think it's on the webmaster's to-do list. Thanks to recall it!

    --
    Julien ÉLIE

    « Il est idiot de monter une côte à bicyclette quand il suffit de se
    retourner pour la descendre. »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Thu Dec 17 17:14:52 2020
    XPost: news.software.nntp

    Hi all,

    % wget http://www.usenet-fr.net/pgp-fr-2020.txt

    Not https? :(

    I think it's on the webmaster's to-do list.  Thanks to recall it!

    Done by the webmaster.
    Thanks for having pointed out the issue!

    => https://www.usenet-fr.net/pgp-fr-2020.txt

    --
    Julien ÉLIE

    « Mais écoutez ce qu'on vous dit, au lieu de taper comme un sourd ! »
    (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Mon Feb 15 22:04:27 2021
    XPost: news.software.nntp

    Hi Richard, Matthew & all,

    My uk.* Control hat is worried about this too - I could make a new key
    and (probably!) adjust the perl lashup that runs uk.* to sign with both
    keys, but the real problem is getting "enough" admins to start trusting
    the new key (and not the old one any more).

    I’d suggest getting started quickly on dual-running for a single
    hierarchy, to discover if there are any problems with it, what the
    upgrade process looks like (given the end goal of trusting only the new
    key), etc.

    Last month, we created 2 newsgroups on the fr.* hierarchy with the new
    4096-bit RSA key. We did not find any problem.
    I would have thought adoption of the new PGP key would have taken far
    more time. It appears that major news servers used by active posters to
    fr.* quickly upgraded the key and created both
    fr.misc.automobile.electrique and fr.misc.actualite.covid19.

    As the previous PGP key is no longer usable, we do not dual-send control articles. Changing the key on news server is the only option for fr.*
    and anyway it is a good thing because actively maintained news server,
    as often as not, couldn't process the previous key any longer (they had
    a too recent GnuPG version for that).

    I think you would be interested in this feedback.

    Next upgrade in 2035 :-)

    --
    Julien ÉLIE

    « Les amis de la vérité sont ceux qui la cherchent, et non ceux qui se
    vantent de l'avoir trouvée. » (Condorcet)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Mon Sep 20 12:54:42 2021
    XPost: news.software.nntp

    Hi Paolo,

    In May 2020:
    @Paolo, it seems that the PGP key of aioe.* has expired

    yes, i know.
    [...]

    I'm currently migrating my news server to a VPS and reinstalling all the associated tooling.
    It is with that sort of migration that I understand well how long it may
    be for new users to set up a whole news server from scratch!
    Impressive to see all the stuff needed :-)


    Well, I'm writing here because I've just seen that the NoCeM PGP key has
    been renewed for Aioe.org:

    pub rsa4096 2021-07-20 [SC] [expire : 2024-07-19]
    8A3C3C2515D0775C85CE765F8D4BD91D2643B3A6
    uid [ inconnue] Aioe.org (Key for NoCEM bags) <nocem@aioe.org>
    sub rsa4096 2021-07-20 [E] [expire : 2024-07-19]

    Well, still expiring in 3 years but good to see that the old one, long
    expired since 2010 is no longer in use.

    I may have missed the announcement of the change though... Was it said somewhere? (I may not be the only one in that case...)

    --
    Julien ÉLIE

    « On appelle ça une insula. C'est une maison où les gens habitent les
    uns au-dessus des autres… » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From D. Stussy@21:1/5 to All on Wed Oct 6 19:00:36 2021
    XPost: news.software.nntp

    What key servers should one periodically check for revisions? The "sks-servers.net" domain stopped service. "pgp.mit.edu" doesn't
    seem to have Usenet keys.

    If there isn't one, should we start one?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matija Nalis@21:1/5 to D. Stussy on Sat Oct 16 17:50:23 2021
    XPost: news.software.nntp

    ["Followup-To:" header set to news.admin.hierarchies.]
    On Wed, 6 Oct 2021 19:00:36 -0700, D. Stussy <spam@spam.org> wrote:
    What key servers should one periodically check for revisions? The "sks-servers.net" domain stopped service. "pgp.mit.edu" doesn't
    seem to have Usenet keys.

    If there isn't one, should we start one?

    Maybe https://keys.openpgp.org/ ?

    --
    Opinions above are GNU-copylefted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)