Valery: (Dropping things that have been resolved.)
>>>>> Then, it is not clear to me how these SHOULD and MUST are aligned with >>>>> each >>>>> other and how the first SHOULD is aligned with "one-time-use" of EE >>>>> certificate. For me this looks inconsistent. Am I missing something? >>>> >>>> I do not recall the discussion that lead to this combination of SHOULD and >>>> MUST. I would be fine with all of >> them >>>> being MUST; however, it aligns with the text in RFC 9632. These words >>>> were originally debated for that >> document. >>> >>> If they were debated for that document, then perhaps some clarification >>> should be given >>> as to how interpret this combination of SHOULD and MUST (at least in this >>> document). >>> For me this combination is inconsistent. >> >> I hope the reference that is being added to RFC 9632 will provide the reader >> with important context. See the >> review from Michael Richardson. > > Russ, I read Michael's review > (https://mailarchive.ietf.org/arch/msg/rtg-dir/p3Lspi2EcdhvI_4om9X44--o6Jc/) > and RFC 9632 and also RFC 6487. I still have doubts whether my understanding > is correct. > > Sorry for being nerd, but literally reading what is written in the draft ,I > believe that the following sequence of actions is valid: > > 1. A new version of a prefixlen file appears > 2. EE wants to sign this file, but it decides not to request a new > certificate and to use an existing one instead > (because of SHOULD) > > And another presumably valid sequence of actions: > > 1. A new version of a prefixlen file appears > 2. EE wants to sign this file and requests a new certificate from CA > 3. CA issues a new certificate (MUST) > 4. EE ignores the new certificate and uses the old one to sign the new file > (because of SHOULD) > > Are these sequences of actions acceptable? First, the CA and the EE are not as separate, but rather one program that does both functions, often with private keys stored in the same HSM. Second, you are correct about the SHOULD. This is not the preferred approach, but it works even when the same private key signs more than one prefix file. > If yes, then the text above (the new text) means (in my understanding) that > the CA MUST always issue a new EE certificate if it is requested to (it is > obvious, IMHO, but let it be), > but the EE is free (in some situations) not to request a new certificate > (or is free to ignore the new certificate) and use an old one instead, > but generally it is preferable to request a new certificate. > > Is this interpretation correct? Correct. I do not see a concern. > If yes, then it would be helpful to at least hint what these situations might > be. > And in this case "one-time-use" of certificates is not guaranteed. Recall the revised paragraph: > The Certification Authority (CA) The CA MUST > generate a new End Entity (EE) certificate for each signing of a > particular prefixlen file. The private key associated with the > EE certificate SHOULD sign only one prefixlen file. That is, > a new key pair SHOULD be generated > for each new version of a particular prefixlen file. > The EE certificate used in this fashion is termed a "one-time-use" > EE certificate (see Section 3 of [RFC6487]). I am not sure what more to say... Russ _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
