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

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

> I know I sometimes mark an intermediate certificate as 
> trusted in testing.  Is this something that happens in the real world?
> 

I haven't seen this & neither have the folks I've asked about it.


> -----Original Message-----
> From: Joseph Galbraith [mailto:galb-list%vandyke.com@localhost] 
> Sent: Saturday, April 03, 2010 10:56 AM
> To: Igoe, Kevin M.
> Cc: ietf-ssh%NetBSD.org@localhost; Douglas Stebila
> Subject: Re: Still more feedback on draft-igoe-secsh-x509v3-01
> 
> On 4/1/2010 08:18, Igoe, Kevin M. wrote:
> >> 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.
> 
> I know I sometimes mark an intermediate certificate as 
> trusted in testing.  Is this something that happens in the real world?
> 
> Thanks,
> 
> Joseph
> 
> >> -----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
> >>
> >>
> 
>