Subject: consensus probe.

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 05 Feb 2002 13:53:51 -0500

Okay, I see significant volume of comments saying that we need to
re-spin the core drafts once again to address the following two issues:

 - Split the ambiguous x.509 text into a new document.  (this seems
   non-controversial at the moment)

 - Clarify the password change text (exactly how is still under
   discussion; let's try to nail this down today).

*sigh*.  i was hoping we were done.

					- Bill

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Feb 2002 14:21:28 -0500

> *sigh*.  i was hoping we were done.

It seems like every time we get close, then some new issue doesn't arise
until "last call" actually happens.  This is both frustrating all around
and a good way not to reach closure.

Could EVERYONE please put ALL their critical unresolved issues on the list
RIGHT NOW, so they can ALL be resolved in the next editorial sweep ??

Thanks,

Ran

---

From: "Joseph Galbraith" <[email-masked]>
Date: Tue, 5 Feb 2002 12:27:08 -0700

>    non-controversial at the moment)

We had at least one suggest that we include

   Signatures are encoded as follows:

     string   signature format identifier (same as public key/cert format)
     byte[n]  signature blob in format specific encoding

following the similar text about public keys.

This seems a good idea to me (though I think
I would omit the "(same as public key/cert format)"
as at least one proposal for x.509 doesn't
follow this rule.  Perhaps "(as specified by
public key/cert format)" would be more
appropriate?

- Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 05 Feb 2002 14:39:56 -0500

> Perhaps "(as specified by

*if we do that*, we may also need a statement that unless otherwise
specified the sig format id == pk/cert format id.

				- Bill

---

From: "Joseph Galbraith" <[email-masked]>
Date: Tue, 5 Feb 2002 12:38:12 -0700

> specified the sig format id == pk/cert format id.

That sounds reasonable.

- Joseph

---

From: Markus Friedl <[email-masked]>
Date: Thu, 7 Feb 2002 13:51:31 +0100

> specified the sig format id == pk/cert format id.

i think this is the only way, since during the initial KEX
both parties only agree on _one_ single format id for
the hostkey.

-m

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 7 Feb 2002 08:07:12 -0700

"Markus Friedl" <[email-masked]>
> both parties only agree on _one_ single format id for

It is possible that the format id for the
public key (x509v3) specifies a signature
format that isn't necessarily of the same
name be used.

For example, we could specify (unambiguously)
that x509v3-sign-rsa keys would use ssh-rsa
signatures.  There is no ambiguity here,
hence my proposal that we spec this flexibly
enough to handle this.

On the other hand, I do agree that we also
need language that says that unless otherwise
specified sig format id is the same as key
format id.

Perhaps the following text would be more
agreeable?

     string   signature format identifier (as specified by the public
key/cert format)
     byte[n]  signature blob in format specific encoding

  Public key / certificate formats that do not
  explicitly specify a signature format identifier
  MUST be considered to use the public key / certificate
  format identifier as the signature identifier.

- Joseph

---

From: "Andersson, Mats" <[email-masked]>
Date: Thu, 7 Feb 2002 16:22:41 +0100 (CET)

On Thu, 7 Feb 2002, Joseph Galbraith wrote:
> For example, we could specify (unambiguously) that x509v3-sign-rsa
> keys would use ssh-rsa signatures.  There is no ambiguity here, hence

Why would we want to do this (though these two signatures happens to be of
the same format as defined in PKCS1), what is the flexibility to be able
to use keys of a certain format for generating (potentially) differently
formatted signatures? If it is not usable for something extraordinary why
include it, it might just confuse some implementation that it sends a key
of format X and receives a signature of format Y (I'm tired so there might
be uses for this but I can't find one except for "lazy" code-reuse :-).

>   format identifier as the signature identifier.

However, doesn't this sound like it can be interpreted as if the signature
format identifier might be ommited alltogether?! (or is it just me beeing
dizzy here?).

Cheers,

/Mats

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 07 Feb 2002 14:39:08 -0500

[ wg chair hat off ]

I'd delete "be considered to", resulting in:

>   Public key / certificate formats that do not explicitly specify a
>   signature format identifier MUST use the public key / certificate

					- Bill

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 7 Feb 2002 13:57:46 -0700

From: "Bill Sommerfeld" <[email-masked]>
> >   format identifier as the signature identifier.

This sound good to me.

- Joseph

---

From: [email-masked] (Niels Möller)
Date: 11 Feb 2002 17:19:41 +0100

"Andersson, Mats" <[email-masked]> writes:

> formatted signatures?

I don't have a strong opinion about this, but I think using several
names for things that are actually the same is a kind of bloat.

I currently use a single symbol table (generated using gperf) that
recognizes all symbol names used in the various specs, and the size of
this table is linear with the total number of symbols. If lots and
lots of symbols are added I'll have to consider splitting it into
several tables for different "namespaces".

BTW, when talking about signatures. ssh-rsa is specified as using
PKCS1 signatures. What is really meant is PKCS1 v1.5. PKCS1 v2
(currently only at draft stage, I think) defines a new improved and
incompatible padding mechanism. That's what happens when referenced
documents change and references don't include version information...

Regars,
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Tue, 12 Feb 2002 21:25:27 +0100

> names for things that are actually the same is a kind of bloat.

I don't think this would be a problem, since you already have
the "format id" for the public-key.  Specifying that
	the "format id" for the signature must be
	equal to the "format id" from the public-key
would simplify things.

> I'll have to consider splitting it into

well, the 'public-key' and the 'signature' namespace would
be the same.

> (currently only at draft stage, I think) defines a new improved and

I did include this information in my "ssh-rsa" draft, but
there was no interest in having explicit information in
the transport draft.