Subject: New draft - NULL Public Key Signatures

From: Ambarish Malpani <[email-masked]>
Date: Tue, 19 Oct 1999 16:16:03 -0700

Hi Guys,
    Given the traffic on this list, it sounds like this IETF is
going to be a pretty boring one. :-)

I have just submitted an individual draft about NULL Public Key
Signatures, which I hope will be part of this working group soon
(make things at the PKIX meeting more interesting).

The main (serious) reason for this draft, is to allow people to
describe data items that may be signed or unsigned more easily
in ASN.1.

Also, having a NULL algorithm is asthetically pleasing.

So here it is.

Please send all your flames/comments to this list.

Thanks,
Ambarish

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

---

From: Marc Branchaud <[email-masked]>
Date: Tue, 19 Oct 1999 17:38:11 -0700

Actually, I think defining a NULL signature algorithm would be pretty useful.

One thing I was looking for in the draft was a defintion of the ASN.1 SIGNED
macro with a NPKA signature, e.g. that the signatureValue shall consist of a
0-length BIT STRING.  I guess this might show up in section 2.5...

Also, in the interest of interoperability I think only one OID should be
defined. (One of the good properties to put in section 6 is that NPKA
produces the same signature results regardless of what hash algorithm is
used.)

Other comments:

2.1.1 - Shouldn't

   S{C, V} => C
   G{E, B} => E

be

   S{C, V} => E
   G{E, B} => C

?  Similarly for 2.1.2...

2.2 - RC5 is a symmetric cipher.  Better to use RSA to avoid confusion.

6 - Another good property: Useful for protocols that were so short-sighted as
to require a signature in the ASN.1 without any regard to other possible
authentication methods.  The NPKA can be used to avoid redundant
authentication.

		Marc

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Mon, 25 Oct 1999 16:07:51 -0400

I just got round to reading the draft. I find the levity unnecessary
and somewhat disturbing.

>1.  Introduction
>
>   This memo defines the NULL public key algorithm. It explains how NPKA
>   NULL algorithm should be used both for digital signatures and
>   encryption/key exchange.

>   Despite the fact that we are not lawyers, we are relatively confident
>   that it is quite safe to use this algorithm for export for any key
>   length size. It is also quite impossible for people to discover your
>   private key via timing, power analysis or other cryptographic
>   methods, as long as you are only using this algorithm.

At the very least I would want to see a very clear message stating
that this mechanism offers no security and is for test purposes only.

Unfortunately the text is written with the assumption that the reader
understands the purpose.

I don't think that the same case can be made for the need for a NULL
integrity algorithm as for a NULL confidentiality algorithm. The need
for the NULL IPSEC method arose because it is very hard to debug 
a system when you can't read any messages

The humourous references to the attacks the scheme is proof against
are I suspect likely to fall flat when some knuckle-brain implements
this and uses it for a real purpose. 

If workers at a nuclear fuel reprocessing plant can be ill trained 
enough to willingly carry buckets of enriched uranium about the place
by hand methinks we should not underestimate the risk of overestimating
the general level of competence.

		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Tuesday, October 19, 1999 7:16 PM
> To: [email-masked]
> Subject: New draft - NULL Public Key Signatures
> 
> 
> 
> Hi Guys,

---

From: Marc Branchaud <[email-masked]>
Date: Mon, 25 Oct 1999 14:37:22 -0700

> Unfortunately the text is written with the assumption that the reader

I disagree about it being only useful for test purposes.  For the same

> a system when you can't read any messages

A NULL signture algorithm is just what the doctor ordered for getting rid of
signature baggage when authentication and integrity are provided by other
means.

I'll grant that the need for this only arises in very specific circumstances,
but to relegate it to just testing is going too far.  The particular
circumstance I have in mind, BTW, is when you're doing something like OCSP
over SSL, _and_ you don't care about future non-repudiation.  In that
specific case, the SSL protection and the OCSP signature are redundant.  It
would be nice to finesse away the OCSP signature.  This would allow
optimizations like reusing the SSL session key, to avoid costly PK
operations.

As to the draft's humour, perhaps it is a bit misplaced.  It would be better
not to undermine the serious applications of the algorithm.

		Marc

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Oct 1999 22:14:39 -0400

Phill & Marc,

This draft, which Ambarish and I discussed months ago, is written in the
same spirit as RFC 2410, the NULL encryption algorithm and its use in ESP.
Maybe we can clue in the otherwise clusless in the security considerations
section, but we have precedent for this style of RFC. I didn't think of it
as anything but a fun document which serves a very minimal (technical)
purpose, but maybe my co-conspirator had more ambitious plans.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 25 Oct 1999 19:59:58 -0700

Stephen Kent wrote:

> section, but we have precedent for this style of RFC.

If you mean the section:

   NULL is a block cipher the origins of which appear to be lost in
   antiquity.  Despite rumors that the National Security Agency
   suppressed publication of this algorithm, there is no evidence of
   such action on their part. Rather, recent archaeological evidence
   suggests that the NULL algorithm was developed in Roman times, as an
   exportable alternative to Ceaser ciphers. However, because Roman
   numerals lack a symbol for zero, written records of the algorithm's
   development were lost to historians for over two millennia.

then out of place humor has just been redefined. Maybe it is indeed
time to consider technical writing rules when submitting RFCs, which
do not have to include references to "Ceaser" [SIC] in order to be
interesting.

Cheers,

Ed Gerck

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Tue, 26 Oct 1999 10:52:14 -0400

Steve,

	Yes, I agree that the joke is pretty funny. I don't think turning
it into an RFC would improve the joke, and we may well find that the
joke ends up being on us.

	Given the ability of companies to mess up big time I can well imagine
some company selling a product claiming to be PKIX compliant, offering only
the NULL signature, export rules, licensing restrictions already mean that
many products ship requiring a crypto engine to be obtained elsewhere.

	If the product runs without security it is inevitable that someone will
use it without. I remember a while back when I persuaded a company that they
had a problem with a crypto implementation, sent them extensive
documentation
on the changes needed. A year later the product was broken with great media
fanfare. Turns out my memo had made it to the documentation but not the
code.

	Or it may just be that I am in a particularly humourless mood given
that there are a couple of nuclear plants in the vicinity and I have been
assured via the television that the events which occurred in Japan could
not occur in the US by 'experts' who clearly lack the level of knowledge of
nuclear processes taught at UK high schools.

	This thing we are building has to be usable by folk who _have_ a
degree in Nuclear Physics :-)

	Folk who need a NULL signature for Test purposes will probably find
that SHA-1 or MD5 can be used to the same effect, with the significant
advantage that integrity problems are revealled. I have a serious concern
that applying NULL in the context envisaged by Marc may remove an integrity
check which in the pure SSL context is not significant but which becomes
significant in a hybrid SSL/message passing system.

	The overhead of SHA-1 is low, we already have the OID. Ergo no need
for a NULL draft to confuse the befuddled holders of doctorates in nuclear
physics.

		Phill

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, October 25, 1999 10:15 PM
> To: Phillip M Hallam-Baker
> Cc: [email-masked]
> Subject: RE: New draft - NULL Public Key Signatures
>
>
> Phill & Marc,
>

---

From: Paul Koning <[email-masked]>
Date: Tue, 26 Oct 1999 11:09:13 -0400

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: Marc Branchaud <[email-masked]>
Date: Tue, 26 Oct 1999 11:17:51 -0700

> many products ship requiring a crypto engine to be obtained elsewhere.

The absence of a NPKA RFC doesn't prevent that.  Nothing in PKIX says that
you MUST (or even SHOULD) support any particular crypto algorithm, or even a
particular OID for a particular algorithm.

> fanfare. Turns out my memo had made it to the documentation but not the

I, for one, am not advocating that anything be able to run without security. 
I don't see what the big deal is about standardizing this.  Like everything
else, those of us who know what we're doing won't hang ourselves with this
rope.  Sure, some idiot might misuse the standard, but the IETF can't prevent
that from happening.  The proper forum to address those kinds of concerns is
something like a PKI accreditation body, that certifies a given level of
conformance.

> significant in a hybrid SSL/message passing system.

Which kind of hybrid contexts are you referring to?  Actually, the answer
isn't that important -- there'll always be some way to abuse the system.  The
existence of such possibilities shouldn't stop us from agreeing on a
technical standard.

> for a NULL draft to confuse the befuddled holders of doctorates in nuclear

The availability of SHA-1 isn't the point.  In fact, using a raw digest
algorithm instead of an "officially" NULL signature is really just muddying
the waters without adding any kind of security benefit.  So there's a digest
of the pack/blob/message?  It doesn't achieve anything.  Much better to
explicitly say "I'm not including any integrity/authentication here, where
you might expect to see it.  You should derive integrity and/or
authentication some other way."

		Marc

p.s. - As to the humour in the draft, let me proclaim my support for as much
humour as possible in these documents.  The stuff's hard enough to read as it
is.  But, if humour upsets people, then I can live (well, exist, really)
without it.