RE: Still more feedback on draft-igoe-secsh-x509v3-01

["Igoe, Kevin M." <kmigoe%nsa.gov@localhost>]

> o The chain encoded MAY be incomplete; it is usually not
>   necessary to include the self-signed certificate specifying
>   the root authority.
> 
>   It is NOT REQUIRED to specify any certificates other than
>   the senders certificate.  If the verifier has a trust anchor
>   that is not the self signed root, these other certificates may
>   not be needed.  However, omitting certificates from the chain
>   may make it more likely that certificate verification will fail
>   because the verifier is not able to build a chain to a trusted
>   anchor.

I'd like our X.509v3 draft to be a "gold standard" for authentication
and would prefer an unbroken certificate chain leading back to a 
root authority. The chain of certs moves the risk that the user's 
public key is bogus down the chain to the risk that the root's 
public key is bogus.  One can then take measures to mitigate the risk 
that the root public key is bogus, these measures being well outside 
the scope of this document. 

P.S. Having the root self-sign their cert isn't very effective, 
whence it being optional.


> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Joseph Galbraith
> Sent: Wednesday, March 31, 2010 8:55 PM
> To: ietf-ssh%NetBSD.org@localhost
> Subject: Still more feedback on draft-igoe-secsh-x509v3-01
> 
> In section 2.  X.509 Version 3 Certificates, we have:
> 
> >    o  The self-signed certificate specifying the root 
> authority MAY be
> >       omitted.
> 
> which seems to indicate that all certificates except the 
> self-signed certificate at the root MUST be included.
> 
> I'm not sure that's what we want (or if that was actually what was
> intended.)
> 
> I think it would be better to say:
> 
> o The chain encoded MAY be incomplete; it is usually not
>   necessary to include the self-signed certificate specifying
>   the root authority.
> 
>   It is NOT REQUIRED to specify any certificates other than
>   the senders certificate.  If the verifier has a trust anchor
>   that is not the self signed root, these other certificates may
>   not be needed.  However, omitting certificates from the chain
>   may make it more likely that certificate verification will fail
>   because the verifier is not able to build a chain to a trusted
>   anchor.
> 
> I'm worried in particular that there might be cases where the 
> signer doesn't have all the certificates necessary to chain 
> to the root easily available.  (I'm not sure if this is a 
> real life use case or not.)
> 
> If we do decide we want to REQUIRE all the certificates, I 
> think we should change the paragraph referenced to make that clear:
> 
> o The self-signed certificate specifying the root authority MEY be
>   omitted.  All other certificates in the chain up to the root
>   authority MUST be included.
> 
> Also, is there any correlation between certificates and OSCP 
> responses?  Currently, there is nothing that constrains the 
> OCSP responses included to have anything to do with the certificate.
> 
> Is there a need for more than one OCSP response per issuer?
> Would it make more sense to do:
> 
>         uint32    certificate-count
>           string    certificate
>           string    ocsp-response-from-certificate-issuer
> 	  [1..certificate-count]
> 
> Use a 0 length string if no OCSP response is available.
> 
> I'm not sure whether this is a good idea or if I'm just 
> showing my ignorance.
> 
> Thanks,
> 
> Joseph
> 
>