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

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

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
>>
>>