Subject: [Cfrg] Naming sig types: sealed/detached -> appendix/recovery?

From: Dan Brown <[email-masked]>
Date: Tue, 26 May 2015 18:45:44 +0000

I'm guessing detached/sealed refers only to API, but the description below
sounds like:

Detached -> signatures with appendix
Sealed -> signatures with message recovery

For the appendix/recovery names, see Handbook of Applied Cryptography,
Section 11.2.

I think that S/MIME and CMS also have a notion similar to the
detached/sealed API: one can choose to include the message signed in the
message body (where a CMS-unable MUA can read it), or to include the message
only in an attachment (.p7m) (where a CMS-unable MUA cannot read it).

If you actually want signatures with message recovery, rather than just the
sealed API, then note that various ECC signatures with recovery are already
standardized in IEEE P1363, ISO 15946(?), and ANSI X9.92.

If CFRG really wants to follow-through with the idea that a verifier should
not allow the message of an invalid signature to be passed along, especially
by bypassing the whole verification step, then maybe CFRG should consider
some variant of a signature scheme with message recovery.

> -----Original Message-----
> From: Ilari Liusvaara
> >
> > I'm curious what the issue is here? (Maybe I don't understand what you
> > mean by "sealed"...)
> 
> "Detached" signatures:
> Sign: PrivKey x Message -> Signature
> Verify: PubKey x Message x Signature -> Good or Bad.
> 
> (This is the usual mode)
> 
> "Sealed" signatures:
> Sign: Privkey x Message -> Signed message
> sign_open: Pubkey x Signed message -> Message or Bad.
> 
> (This is mostly seen in NaCl library[1])
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 May 2015 13:53:32 -0700

> From: Cfrg [mailto:[email-masked]] On Behalf Of Dan Brown
> Sent: Tuesday, May 26, 2015 11:46 AM
> To: [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: [Cfrg] Naming sig types: sealed/detached -> appendix/recovery?
> 
detached/sealed
> API: one can choose to include the message signed in the message body
(where
> a CMS-unable MUA can read it), or to include the message only in an
attachment
> (.p7m) (where a CMS-unable MUA cannot read it).

CMS is currently designed only to work for signature with appendix
algorithms, but not for the reason cited above.  That is covered by
including a hash of the main body in the actual content that is signed.
Nobody has gone through the CMS structures to look at how a recoverable
signature would be encoded in the current ASN.1 structures.  It could be
interesting, but I think probably doable.  I would have to go through the
list of signed attributes to determine if there are any that govern how a
signature is validated, but I don't believe that there currently are.  All
attributes about things like finding a certificate are duplicated if it is
considered to be important to be signed as well.

Jim

> If CFRG really wants to follow-through with the idea that a verifier
should not
> allow the message of an invalid signature to be passed along, especially
by
> bypassing the whole verification step, then maybe CFRG should consider
some
> variant of a signature scheme with message recovery.
> 
> 
> > > I'm curious what the issue is here? (Maybe I don't understand what
> > > you mean by "sealed"...)
> >
> > "Detached" signatures: