Subject: RE: I-D ACTION:draft-ietf-secsh-transport-18.txt

From: Scott Rankin <[email-masked]>
Date: Tue, 15 Jun 2004 13:57:06 -0700

Sorry if this is already known. I couldn't look in the bug tracking system
as it required a username and password.

Just a couple questions.

In section 6.6 Public Key Algorithms.

x509v3-sign-rsa and x509v3-sign-dss are listed as "defined" formats. That
said, I have been unable to find where these are defined (and there is no
citation of this definition in this section). 

Perhaps this is why RFC2459 (and soon to be RFC3280 per earlier mails) was
listed in the References at the end of the document? 

Is it RFC3280 or RFC3279 which defines x509v3-sign-rsa and x509v3-sign-dss?

All the other public key algorithms have at least an additional sentence
below the table of formats as well. Maybe that is all the document needs.

I have scoured through the mailing list archives and the ietf pkix working
group and secsh internet drafts and rfcs and have come up dry. Any thoughts?

This sentence,
"The key type MUST always be explicitly known (from algorithm
   negotiation or some other source)" sounds awkward to me. I think it is
the combination of MUST and always. It seems redundant.

cheers,
scott rankin

---

From: [email-masked] (Niels Möller)
Date: 16 Jun 2004 09:00:45 +0200

> citation of this definition in this section). 

The last thing this group said on x509, iirc, was that use of x509
needs to be specified in more detail, and that it should be done in a
separate document. And that separate document doesn't yet exist.

I think someone mentioned that there exists one or two implementations
that support x509, so my advice is that you figure out what they do,
and try to get it written down.

(Personally, I'm not very interested in x509, so I may have missed
something).

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Jun 2004 06:10:06 -0700 (PDT)

Hi Scott,

I've opened Ticket #474: "WG - transport - x509v3-sign-*" from your
excellent catch.  The responses so far indicate that it's been well
discussed before so hopefully we can resolve this one quickly.

The instructions for the Issue Tracker are here:
  http://rt.psg.com/

Access to the Issue Tracker starts here:
  https://rt.psg.com/

If you're not one of the people who can open/close/modify tickets, then
your access is with
  username = ietf
  password = ietf

Thanks,
Chris

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 16 Jun 2004 23:57:25 +1200

>citation of this definition in this section).

The last time this came up I dug through the entire archives and posted a
summary of all the posts I could find on the topic (it'll be in the archives
somewhere, grep for my From: address).  The conclusion was that no-one could
agree on how this should work, and no-one was interested enough to sit down
and sort it out.  Unfortunately those two ID strings are still present in the
spec although they're not useful for anything, I think it'd be best to either
remove them entirely (make them accessible via a vendor-specific string if
anyone does actually want to use them), or just include a note to say that
these values exist for historical purposes but aren't used for anything, sort
of like the "entry" keyword in K&R C.

Peter.

---

From: Roumen Petrov <[email-masked]>
Date: Wed, 16 Jun 2004 12:14:09 +0300

Hi Scott,

Following lines mysterious disappear after 
draft-ietf-secsh-transport-12.txt (I guess).
================================================
....
The "x509v3-sign-rsa" method indicates that the certificates, the public
key, and the resulting signature are in X.509v3 compatible DER-encoded
format. The formats used in X.509v3 is described in [RFC-2459]. This
method indicates that the key (or one of the keys in the certificate) is
an RSA-key.

The "x509v3-sign-dss". As above, but indicates that the key (or one of
the keys in the certificate) is a DSS-key.
================================================

Might ssh.com don't like other to implement X.509 certificates support ?

To write new draft for 5 lines as some people suggest (see list archive) 
is waste of time.
Note that their secsh implementation don't support X.509 certificates.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 17 Jun 2004 00:04:49 +1200

Roumen Petrov <[email-masked]> writes:

>The "x509v3-sign-rsa" method indicates that the certificates, the public key,
>and the resulting signature are in X.509v3 compatible DER-encoded format. The
>formats used in X.509v3 is described in [RFC-2459]. This method indicates that
>the key (or one of the keys in the certificate) is an RSA-key.

This doesn't actually describe the format - it's about as useful to
implementors as the equivalent reference to PGP sigs (that is, not at all).
These things really should be removed from the spec rather than being left in
an undefined state, or at least marked as reserved for future use.

>To write new draft for 5 lines as some people suggest (see list archive) is
>waste of time.

It's going to take a *lot* more than those 5 lines to define everything, and
since no-one seems to be interested in it, reserving it to be defined in a
separate document is a good idea.  If you really want this so badly, you could
always write the RFC yourself :-).

Peter.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jun 2004 11:11:00 -0500

> always write the RFC yourself :-).

Yup.  And for merely reserving the names the numbers (IANA) doc seems
best:

"
4.3 Public Key Algorithm Names

   Algorithm name                Reference
   ---------------               ---------
   ssh-dss                       [SSH-TRANS, Section 4.6]
   ssh-rsa                       [SSH-TRANS, Section 4.6]
   x509v3-sign-rsa               [SSH-TRANS, Section 4.6]
   x509v3-sign-dss               [SSH-TRANS, Section 4.6]
   spki-sign-rsa                 [SSH-TRANS, Section 4.6]
   spki-sign-dss                 [SSH-TRANS, Section 4.6]
   pgp-sign-rsa                  [SSH-TRANS, Section 4.6]
   pgp-sign-dss                  [SSH-TRANS, Section 4.6]
"

Just replace the reference to the transport I-D section 4.6 with
"[TBD]" and remove all references to undefined host key algs from the
transport I-D.

Nico
--

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 16 Jun 2004 20:33:57 -0400

> Date: Wed, 16 Jun 2004 11:11:00 -0500
> From: Nicolas Williams <[email-masked]>
> To: Peter Gutmann <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
>         [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt
> 

Indeed.  Several attempts to recruit an author for such a document
have failed.  

Any *new* volunteers?

> 4.3 Public Key Algorithm Names

This is probably the best bet.

.. though I've heard rumors that some folks have indeed implemented
this and may be using the code point already, in which case we may
need to use a different name for the standard version..

							- Bill

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jun 2004 19:58:56 -0500

> > Yup.  And for merely reserving the names the numbers (IANA) doc seems
[...]
> need to use a different name for the standard version..

Not if the standard matches those implementations, yes otherwise.

Either way, not an issue until someone steps up to actually spec the
x.509 and/or pgp host key algs.

Nico
--

---

From: Roumen Petrov <[email-masked]>
Date: Thu, 17 Jun 2004 09:27:07 +0300

Peter Gutmann wrote:

>[SNIP]
>since no-one seems to be interested in it
>  
>
Please check [email-masked] and 
[email-masked] lists.
Note one of request was openssh to support 'x509v3-sign-*' only ;-) !

>[SNIP]