Re: draft-igoe-secsh-x509v3-00

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Jeffrey Hutzelman wrote:
> --On Wednesday, November 18, 2009 04:50:28 PM -0700 Joseph Galbraith 
> <galb-list%vandyke.com@localhost> wrote:
>
> > o Do we want to require processing of (or give guidance with regards to)
> >    any extensions, such as BasicConstraints, KeyUsage, and
> >    SubjectAltName?
> >
> > o Do we need language about respecting critical extensions or rejecting
> >    the certificate?
>
> We probably should require that KeyUsage include one or more of 
> digitalSignature, keyEncipherment, and/or keyAgreement, depending on the 
> requirements of the key exchange algorithm in use.

If I'm not mistaken, all current key exchange algorithms
(all derivatives of diffie hellman) only require digitalSignature,
since the hostkey isn't actually used during the key agreement
stage.  Does that sound correct?

(Though there may be future algorithms that require the
other usages.)

> I don't think we need specific language detailing how to validate 
> certificates, beyond "MUST comply with RFC5280".
>
>
>
> > o Do we want to define any extended key usage key purpose ids?
>
> IMHO we should, because defining an EKU key purpose ID is the only way 
> to allow issuance of a certificate that can be used _only_ for SSH, and 
> not for any other application.

In that case, the original (abandoned) x509v3 draft included
these:

       id-kp-ssh-server OBJECT IDENTIFIER
         ::= { 1.3.6.1.4.1.2213.15.1.1 }
       id-kp-ssh-client OBJECT IDENTIFIER
         ::= { 1.3.6.1.4.1.2213.15.1.2 }
       id-kp-ssh-clientHostbased OBJECT IDENTIFIER
         ::= { 1.3.6.1.4.1.2213.15.1.3 }

I don't recall how we came up with the oids...

> > o When we were working on x509v3 before, people seemed to want to
> >    include revocation data as well as chain data; I was never quite
> >    sure whether this was really needed or if it was gold plating, so
> >    to speak.
>
> For most protocols, including an OCSP response alongside a certificate 
> is an optimization, because it allows the recipient to verify that the 
> certificate is valid without independently contacting an OCSP server.  
> This is particularly interesting when the party that includes the OCSP 
> response uses its certificate frequently in a short period of time, 
> because it can cache and reuse the OCSP response for as long as it is 
> valid, reducing load on OCSP servers.
>
> For SSH, this capability might be valuable chiefly because it would 
> permit clients to provide OCSP responses to SSH servers living in 
> restricted networks or under other constraints which might prevent them 
> from contacting the OCSP server directly.

Then we might do something like:

> This key format has the following specific encoding:
>
>      string    "x509v3-ssh-dss" / "x509v3-ssh-rsa" /
>                "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2"
>      uint32    certificate-count
>      string    certificate[1..certificate-count]
>      uint32    ocsp-response-count
>      string    ocsp-response[0..ocsp-response-count]

If I'm understanding the PKI correctly, ocsp-response-count should
be at most certificate-count - 1 (once ocsp response for each issuing
certificate in the chain.)

Thanks,

Joseph