IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
>>
>>
Home |
Main Index |
Thread Index |
Old Index