Valery:

>>> 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.
> 
> OK, thank you for clarification.
> 
>> 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.
> 
> I agree, but in this case this is not "one-time-use".
> 
>>> 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.
> 
> Fine, I'm glad I understood the text correctly.
> 
>>> 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...
> 
> We obviously disagree that with the current "SHOULDs" this can be 
> generally termed as "one-time-use of EE certificate" (at least in my reading 
> of RFC 6487). 
> 
> But since this is only a remark, I can see it as a nit, not as an issue.
> 
> Thank you for the explanation.

If the SHOULDs are followed, then the EE provate key is "one-time-use".

Russ
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to