Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn

Russ Housley <> Tue, 06 November 2018 10:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F987130F7C for <>; Tue, 6 Nov 2018 02:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HzKdIpwQCwqt for <>; Tue, 6 Nov 2018 02:18:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 097BD130E66 for <>; Tue, 6 Nov 2018 02:18:54 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2780300AA5 for <>; Tue, 6 Nov 2018 05:18:51 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id Uv_F4csLL00d for <>; Tue, 6 Nov 2018 05:18:50 -0500 (EST)
Received: from ( []) by (Postfix) with ESMTPSA id 69468300425; Tue, 6 Nov 2018 05:18:49 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Russ Housley <>
In-Reply-To: <019601d475b9$578c9ea0$06a5dbe0$>
Date: Tue, 6 Nov 2018 05:18:45 -0500
Cc: SPASM <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <014401d47581$5fe919d0$1fbb4d70$> <> <016001d4758c$67daa2c0$378fe840$> <> <019601d475b9$578c9ea0$06a5dbe0$>
To: Jim Schaad <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Nov 2018 10:19:03 -0000


>>>>> * Section 2 - What operational considerations are there for when to
>>>>> retire the old Root CA certificate when a new one has been
>>>>> discovered and is to be used?
>>>> I'm not sure what you are requesting.  Install the new one, and
>>>> remove the old one?
>>> When you install the new one, I don't believe that you are going to
>>> remove the old one.  There are still going to be valid certificates
>>> running around that will chain to the old root until you have done all
>>> of the issuing of certificates to the new root.  This is going to take
>>> time.  Additionally, if you are looking at something like the mail
>>> case you want to keep the old root but mark it as being "expired" so
>>> that you can validate the chain of certificates.
>> If one follows the old-with-new and new-with-old advice in RFC 2510, then
>> the replacement should not cause any disruption.  If you think it is useful, an
>> operational consideration about this can be added.
>>> This means that it might be some time before the old one is removed.
>> It should not need to linger...
> Since it was not obvious to me, then yes the hint should be included.

Will do.

>>>>> * Section 5? - I think that a discussion of the difference between
>>>>> signature and public key algorithms might be needed here and that in
>>>>> order to do the roll over the signature on the new self-signed cert
>>>>> needs to be "acceptable".  It might even be necessary to have a
>>>>> discussion of why you are not fixing the signature algorithm at the
>>>>> same time that you are fixing the public key value.  - Think an
>>>>> ECDSA new key, but it comes with an
>>>>> ECDSA-with-md5 signature algorithm (and yes I know that is not real).
>>>> A trust anchor public key is always a digital signature key.  I
>>>> assume that all CAs know that.
>>>> The CA needs to ensure that the new key is as strong or stronger than
>>>> the key that it is replacing.  Is there really anything more to say?
>>> But why are you not making the determination of the signature
>>> algorithm that is going to be used by the new key at the same time
>>> that you are generating it.
>> The hash is computed on the SubjectPublicKeyInfo, so it includes the
>> algorithm identifier.
>>> The new key could be an ECDSA key of a longer length than the previous key.
>>> This would be appropriately reflected and checked.  The issue is that
>>> the CA does not say what the signature algorithm is.  This means that
>>> I might be able to attack by using a signature algorithm that is
>>> weaker than what the CA intended it to be.  For algorithm where the
>>> signature OID and the public key OID are the same, this is not
>>> possible.  However for algorithms where that is not the case it is a
>>> possible way for an attack to be pushed forward.
>> Right, the algorithm identifier of the public key is nailed down, but other
>> details are not.  I do not see a way to exploit this without the private key
>> being compromised.  Such a compromise would, of course, have many more
>> issues to sort out.
> If I can second preimage the hash algorithm, for some signature algorithms I
> would be able to do the compromise.  It was odd to me that this was not
> noted but I would not insist on it.

Okay.  This is details on the same issue that you raise earlier in the thread.