revoking ssh-cert.pub with serial revokes also younger certs

[Douglas E Engert]

https://www.ietf.org/rfc/rfc5280.txt

4.1.2.2.  Serial Number

    The serial number MUST be a positive integer assigned by the CA to
    each certificate.  It MUST be unique for each certificate issued by a
    given CA (i.e., the issuer name and serial number identify a unique
    certificate).  CAs MUST force the serialNumber to be a non-negative
    integer.

    Given the uniqueness requirements above, serial numbers can be
    expected to contain long integers.  Certificate users MUST be able to
    handle serialNumber values up to 20 octets.  Conforming CAs MUST NOT
    use serialNumber values longer than 20 octets.

    Note: Non-conforming CAs may issue certificates with serial numbers
    that are negative or zero.  Certificate users SHOULD be prepared to
    gracefully handle such certificates.

On 9/17/2019 1:26 AM, Jakob Schürz wrote:
> Thank you for your answer.
> 
> Am 17.09.19 um 02:02 schrieb Damien Miller:
>> On Mon, 16 Sep 2019, Jakob Schürz wrote:
>>
>>> Hi Daminan!
>>>
>>> Hmmm... thought about a little...
>>>
>>> when i use -vvv with ssh-keygen -Qf i see "debug1:..." So i think, debug
>>> is compiled in.
>> debugging is compiled in generally, but the the recipe I mentioned turns
>> on extra KRL debugging.
> 
> I think, it's not necessary now.
> 
>>
>>> ssh-keygen --help gives me
>>>
>>> ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number] file ...
>>>
>>> so... option -z is not the serial of the certificate, it is the
>>> version-number of the KRL-File...
>> oops, yes.
> This means, with -z i can give my KRL-File a serial-number? How can i
> dump the revoke-file infos?
>>
>>> My openssh-Verision from Debian is 1:7.4p1-10+deb9u7. Maybe, this
>>> openssh-version does not support revoking a certificate by it's
>>> serialnumber.
>> It almost certainly does, but you'd need to use a KRL specification file.
>> See the "KEY REVOCATION LISTS" section in the ssh-keygen manpage.
> This section is not clear enough. Please add some examples.
>>
>>> This leads me to the next question... The serial-number of
>>> a certificate is uniq over all certificates, or is it allowed, to
>>> increment serial-numbers for each certificate separate? How is the design?
>> what goes in the serial number is totally up to the CA. OpenSSH doesn't
>> make any authentication decisions based on it - it's in the certificate
>> mostly to allow very compact revocation lists.
> 
> 
> I played around a little. I have a bunch of different certificates
> (different users, rsa, ecdsa, ed25519-keys...). Some with the same
> serial-number, some with different. I set up my CA to increment each
> certificate for each pubkey separate. This means, The pubkey
> id_userA_rsa.pub and id_userA_ecdsa.pub start with 1 and each counts up
> for itself.
> 
> Then i tried to revoke the certificate for id_userA_rsa.pub
> (id_userA_rsa-cert.pub) with serial 8. The KRL says, i have to fill one
> line with
> 
>      serial: 8
> 
> i can not add a key-id to the serial-number. Only "serial: 8" is possible.
> When i check, if certificate is revoked with
> 
>      ssh-keygen -Qf ... i get a "REVOKED". It's ok.
> 
> id_userA_ecdsa-cert.pub has serial 9, so this certificate is not
> revoked. But if it has also serial 8, both certificates are revoked.
> 
> If i write
> 
>      id: userA at hostX
> 
> in my KRL, all certificates for this pubkey (id) are revoked,
> independend from their serial. Its the same effect as if i give the path
> to id_userA_rsa-cert.pub or id_userA_rsa.pub.
> So if i wand a clean an proper revokation of old certificates, there
> MUST be only one incremental-line over all certificates.
> 
> This is NOT clear in the man-pages.
> 
> Would i be possible, that someone update the docs, that it gets a bit
> more understandable for newbies (as me).
> 
> thank you
> 
> 
> Jakob
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

-- 

  Douglas E. Engert  <DEEngert at gmail.com>