I understand that the issuer has no choice.
What I can't see is how any validator will accept the new certificate.
The new cert will fail the validation check required by the field in the
existing certificate.
So it seems that the only remedy is to wait until the exist certificate
expires, so th
Joel:
If access to the key is lost, the commitment is broken, so the Root CA must
make a fresh start using a completely unrelated key. Maybe the word "remedy"
is creating the wrong impression for you.
Russ
> On Jan 4, 2019, at 6:42 PM, jmh.dir...@joelhalpern.com wrote:
>
> If the new self-s
If the new self-signed cert uses a new key, wouldn't that be rejected as
violating the promise in the current cert? I am missing something.
Thanks,Joel
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
Original message From: Russ Housley
Date: 1/4/19 17:57 (GMT-05:0
Joel:
Thanks for the review.
> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
> Reviewer: Joel Halpern
> Review Date: 2019-01-04
> IETF LC End Date: 2019-01-10
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is nearly ready for publication as an Informational
Reviewer: Joel Halpern
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more inf
Reviewer: Christer Holmberg
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
Fo
Hi,
…
>> Example: pn-prid = 00fc13adff78512
>>
>> For more information about the APNs Topic and device token:
>>
>> SB> Is the following part of the example? If so it could usefully be
>> delimited
>> SB> as such, otherwise, I don't understand why it is not a normal document
>> SB> reference