> On Oct 21, 2025, at 12:22 PM, Michael Richardson <[email protected]>
> wrote:
>
>
> Mahesh Jethanandani <[email protected]> wrote:
>> Thanks first of all for providing your feedback. Can you confirm if the
>> -08 version of the draft addresses your comments?
>
> Mostly.
> I still find that there is text in section 6, re-explaining CMS.
> I was told that this would be removed, but -08 still has it.
I am confused. You asked for the following to be removed:
>>> Identifying the private key associated with the certificate and
>>> getting the department that controls the private key (which might be
>>> stored in a Hardware Security Module (HSM)) to generate the CMS
>>> signature is left as an exercise for the implementor.
And, that was removed.
> ... reiterating:
>
> In particular, it's difficult from reading the description to know if there
> are significant changes to CMS being detailed, or if it's just a retelling.
> {And I've used CMS lots}
I do not see it. I just reread Section 6 in the -08 version, and these is not
any text that looks like a summary of CMS. I just see a straightforward
specification of CMS SignedData in this context.
>
> The EUF concerns with CMS should be clearly articulated.
> (Mention this in point 5 of that section)
I disagree. For my coauthors and others that might not be familiar with EUF,
it stands for Existential Unforgeability, and it is a security property in
digital signature mechanisms. A signature mechanism is EUF-secure if it is
computationally infeasible for an attacker to create a valid signature for any
new message, even messages with crazy formatting, even if the attacker has
previously queried the signer for signatures on other messages. This is not
possible here because of the "one-time-use" EE certificate.
> I understand the desire to have files with sane (CRLF) line endings.
> I don't understand why this goes into the authentication process as an
> explicit canonicalization step.
> Sign whatever is in the file; it's not email subject to mutations.
> In email, we have to worry about 7bit<->8bit translations, and some systems
> removing trailing white space, ... but this isn't the case.
This was discussed in reply to your original message. Once again, we want to
use the same approach as RFC 9632. Since lines are being extracted from a
file, canonicalization makes sure the signer and the validator are using the
same bytes.
> I don't understand what attack/risk is being dealt with by having a
> (local/subordinate) CA sign a new EE, and then throw that away after using it
> once. I can't say that I understand RFC6487's reasons for having these
> one-time-use EE, either.
> Are people worried that the private key will get lost or disclosed?
> Why not the same worry about the local CA's key?
This is explain in RFC 6487, and it is the way that all signed objects are
handled in the RPKI.
> The signatures for RPKI ROAs and for prefix lengths (and for geofeed) are not
> updated that often. If geofeed and prefix lengths are adopting this
> one-time-use EE because RPKI does it, and common tooling is good, then I'm
> fine with that.
I believe that is what we said in the original response. Sorry if we were not
clear.
Russ
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
