Subject: RE: New draft - NULL Public Key Signatures

From: Ambarish Malpani <[email-masked]>
Date: Wed, 27 Oct 1999 11:14:06 -0700

Hi Paul,
    The reason is to allow a way to indicate that something is
not signed even when the formal syntax requires it to be signed.

One example as Marc B. pointed out was unsigned OCSP responses.
Another potential example is to actually issue self-signed certs
with this kind of a signature - to clearly indicate that the
signature on the cert doesn't really mean much.

Another reason was to allow protocols to actually require signatures
everywhere, an support this algorithm if the signature was
optional - for example, in the OCSP protocol, we have an optional
signature section on the request - makes the syntax quite a bit
uglier than just requiring a signature and allowing for NULL
signatures.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 8:09 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: New draft - NULL Public Key Signatures
> 
> 
> I'm not having much success seeing the analogy between Null ESP and
> null signature, nor a reason why the latter is useful and should be
> standardized. 
> 
> Null ESP serves a specific purpose, which is well documented: to
> provide data integrity without simultaneously providing
> confidentiality.  While that's not often desirable, there are
> certainly cases where it is a useful service.
> 
> But I don't see that the analogy carries over to null 
> signatures.  The 
> political/legal issues that stand in the way of universal
> confidentiality don't apply.  As far as I can tell from the RFC, the
> purpose is really just an encoding hack: a way of specifying that
> signatures are omitted without saying it explictly.
> 
> So what good is that?
> 
> 	paul
>

---

From: Paul Koning <[email-masked]>
Date: Wed, 27 Oct 1999 14:22:25 -0400

>>>>> "Ambarish" == Ambarish Malpani <[email-masked]> writes:

 Ambarish> Hi Paul, The reason is to allow a way to indicate that
 Ambarish> something is not signed even when the formal syntax
 Ambarish> requires it to be signed.

Yes, I realize that; the draft makes that clear.

My point is that this is a rather obscure way of providing this
capability.  If it's desirable to allow things to be unsigned, let the 
syntax do so.  Using the syntax for "signed data" where the signature
is actually meaningless is, at best, a weird encoding hack and, at
worst, higly misleading and confusing.

 Ambarish> One example as Marc B. pointed out was unsigned OCSP
 Ambarish> responses.  Another potential example is to actually issue
 Ambarish> self-signed certs with this kind of a signature - to
 Ambarish> clearly indicate that the signature on the cert doesn't
 Ambarish> really mean much.

Why is it useful to be able to issue self-not-signed certs?  The fact
that this proposal allows such things to be done doesn't mean it is
something that *should* be done.  (Dan Harkins, are you there?  :-) )

 Ambarish> Another reason was to allow protocols to actually require
 Ambarish> signatures everywhere, an support this algorithm if the
 Ambarish> signature was optional - for example, in the OCSP protocol,
 Ambarish> we have an optional signature section on the request -
 Ambarish> makes the syntax quite a bit uglier than just requiring a
 Ambarish> signature and allowing for NULL signatures.

But declaring the signature to be optional is far clearer.  And why
does that make the syntax ugly?  I thought one of the benefits of
ASN.1 is that it's trivial to describe optional components.

	paul