• PKEY_DROP Echo Suggestions

    From Moderator@1:3634/12 to All on Mon Feb 1 00:20:36 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Feb 15 00:00:14 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Mar 1 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Mar 15 00:00:16 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Nov 1 00:00:10 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Nov 15 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Dec 1 00:05:34 2009
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Dec 15 00:00:08 2009
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Jun 1 00:00:18 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Jun 15 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Sep 1 00:00:18 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Sep 15 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Dec 1 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Apr 1 00:30:54 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Apr 15 00:00:12 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Jul 1 00:00:10 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Jul 15 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Dec 15 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Jan 1 00:00:18 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Jan 15 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Oct 1 00:00:18 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Oct 15 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat May 1 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat May 15 00:13:22 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Nov 1 00:00:10 2009
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Nov 15 00:00:16 2009
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Aug 1 00:00:08 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Aug 15 00:00:06 2010
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Jan 1 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Jan 15 00:00:08 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Feb 1 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Feb 15 00:00:08 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Mar 1 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Mar 15 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Apr 1 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Apr 15 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun May 1 00:00:08 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun May 15 00:00:20 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Jun 1 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Jun 15 00:00:14 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Jul 1 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Jul 15 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Aug 1 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Aug 15 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Sep 1 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Sep 15 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Oct 1 00:00:16 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Oct 15 00:00:10 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Nov 1 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Nov 15 00:00:08 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Dec 1 00:00:18 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Dec 15 11:13:14 2011
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Jan 1 00:00:10 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Jan 15 00:00:18 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Feb 1 00:00:10 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Feb 15 00:00:18 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Mar 1 00:00:10 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Mar 15 00:03:50 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Apr 1 00:00:16 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Apr 15 00:00:18 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue May 1 00:00:20 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue May 15 00:00:10 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Jun 1 00:12:10 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Jun 15 00:00:18 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Jul 15 00:00:22 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Aug 1 00:00:10 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Aug 15 00:00:14 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Oct 1 00:00:16 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Oct 15 00:00:14 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Nov 1 00:00:16 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Nov 15 00:00:16 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Dec 1 00:00:16 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Dec 15 00:00:18 2012
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Jan 1 00:00:06 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Feb 1 00:00:14 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Feb 15 00:00:06 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Mar 1 00:00:08 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Mar 15 00:00:14 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Apr 1 00:00:14 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Apr 15 00:00:08 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed May 15 00:00:16 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Jun 1 00:00:18 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Jul 1 00:00:10 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Jul 15 00:00:18 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Aug 1 00:00:20 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Aug 15 00:00:20 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Sep 1 00:00:16 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Oct 1 00:00:20 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Sep 15 00:00:08 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Tue Oct 15 00:02:28 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Nov 15 11:20:22 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Dec 1 00:00:18 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sun Dec 15 00:00:20 2013
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Jan 1 00:00:20 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Jan 15 00:00:18 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Feb 1 00:00:20 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Feb 15 00:00:16 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Mar 1 00:00:10 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Mar 15 00:00:16 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Fri Aug 1 05:47:10 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Sep 1 00:00:18 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Wed Oct 1 00:00:16 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Sat Nov 1 00:00:18 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Mon Dec 1 00:00:12 2014
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)
  • From Moderator@1:3634/12 to All on Thu Jan 1 00:00:18 2015
    -----BEGIN PGP SIGNED MESSAGE-----


    PKEY_DROP Echo Guidelines: rev. 2 JUL 01
    Posting Frequency: 1st and 15th of the month.
    -----------------------------------------------------------------------

    KEYNOTES:

    ONE-

    If you have generated a public-key of 1024 bits with 2.3a or later
    versions of PGP, you probably don't need to revoke the old one and make
    a new one. This is particularly true if your key was made with any of
    the 2.6 generations. If you're worried about getting 2.6.2 or later on
    your key, don't make a new one, just re-export your public-key with the
    newer version of PGP using the standard key export command:

    PGP -kxa youruserid youruserfilename

    and then copy the new copy of your public-key to your file directory so
    people can file-request or download it.

    TWO-

    MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
    will put his/her secret-key into circulation. That's BAD!

    THREE-

    When making your first public-key pair or a new public-key pair, go for
    the 1024 bit size. Don't make your key any more vulnerable than you
    need to regardless of how long it takes to compile it. If you go for
    the 2K size key, keep in mind that 2047 bits is NORMAL for the stock
    PGP.

    FOUR-

    MAKE SURE you put all your possible userids on your public-key after
    you generate it and before you circulate it for use and/or signatures.
    It is especially important to be sure that your standard User Name is
    on there EXACTLY as it appears in the From: line on your Netmail and
    Echomail. This makes it much simpler for folks to encrypt to your name
    as detected in a reply.

    It also makes life simpler if your Netmail name, your public-key name
    and your FidoNet Nodelisting name are all the SAME name!

    FIVE-

    It is recommended that individual, public-keys be made available via
    Netmail or by file-request with the magic filename: PGPKEY and that the
    public-key provided for that request by given a distinctive filename
    using part or all of each provider's name and address. For example, on
    my system, a file-request of PGPKEY will give MFLKEY.ASC to the
    requesting system. A magic filename of KEYRING will yield my working
    Public Keyring as MFLPUB.PGP. INETRING will give you PUBKEYS.PGP which
    is a ring i downloaded from one of the large public keyservers some
    years back. This will avoid duplicate overwriting and make it easier
    to track the keys. Using standard magic filenames will make it easier
    to find keys and keyrings on different systems.

    [NOTE: PGPKEY is usually the magicname for the SYSOP's public-key on a
    given system. Users may ask their Sysops to make the User keys
    available by specific filename the User can advertise.]

    SIX-

    DO NOT SIGN someone's public-key UNLESS you have obtained it directly
    from them or their system under password or by direct file-request.
    Signing the keys of others without knowing those keys came from who
    they claim to be from dilutes the web of trust. You do not have to sign
    a key to add it to your keyring.

    SEVEN-

    IF you are going to upgrade your key size from smaller to larger, be
    sure to sign your new key with your old, established key FIRST and
    BEFORE you revoke your old one. It will give you a head-start on
    trusting the new one. If you don't know how to force PGP to sign [or do
    any other key feature] by KeyID number instead of UserID, just remember
    to preface the KeyID with 0x and PGP will know which key you mean to
    use for any specific operation.

    SPECIAL NOTE ---

    If you lose your secret-key password [or forget it] or your secret-key
    in a drive crash [because you failed to back it up on floppy], you
    cannot issue a revocation certificate. In that case, you should make a
    general announcement in all related Echos that your old key should be
    disabled using the PGP disable command [PGP -kd userid] for your
    userid. That keeps your useless key on their keyrings [so they won't be
    replaced from other lists who didn't get the word] and permits them to
    add a new key from you without one interfering with the other. BACKUP!
    BACKUP! BACKUP! [clear?] [grin]

    This Echo is available on the Zone 1 Backbone. This Echo has been
    Elisted since ELIST211. Please feel free to announce this Echo to all
    interested participants in your area.

    Thanks.

    Mark Lewis, 1:3634/12, wkitty42@alltel.net

    Conference Moderators


    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: Privacy is a right to fight for.

    iQCVAwUBO0SvmJsj1FW2DCDFAQH8iAP9HZzErX4NaSvkMcg4tolk/X2Z4Kf8hx+l m3Clq1evryFwH9MEe0dRk5yYjaOpM23CcuM3uonegHEB8HKzUVE3+fcxsXKGmdLP whvlRiZvOVDZRvCwBkpTIPoyfpg6+Bt1VGbUn0LxFqpq20hf/mbYB57bLAXkFSv4
    byG6uvHowpw=
    =M9Du
    -----END PGP SIGNATURE-----


    * Origin: (1:3634/12)