On 01/19/16 11:49, Jakob Bohm wrote:
> On 19/01/2016 02:49, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this
>> year
>> which chain to root CAs in Mozilla's program:
>>
>> - https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root
>> [DigiCert]
>> via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"
>>
>> Also, the OCSP responder for this certificate appears to not include a
>> nextUpdate field.
>>
>
> Does the OCSP spec say what "no nextUpdate" should default to? Like maybe
> "dontcache, expires instantly".
>
>>
>> - https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
>> [SECOM] via subCA "YourNet SSL for business"
>>
>> Also, this certificate is also missing OCSP information and appears to be
>> being
>> served without OCSP stapling support.
>>
>
> If there is no OCSP, it obviously cannot be stapled.
The CA/Browser forum BRs contemplate OCSP stapling without an OCSP responder
being listed in the certificate in section 7.1.2.2.c ("The HTTP URL of the
Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
“staples” the OCSP response for the Certificate in its TLS handshakes
[RFC4366].") I assume the idea is that the OCSP responder URL would be manually
configured in the server and that this would make the certificate slightly
smaller.
> In addition to the above, note that *code signing* and *document
> signing* certificates may be issued after the deadline for SSL SHA-1
> certificates, because some important relying party software cannot be
> upgraded to support modern signature hash algorithms (most notably
> Microsoft platforms released before 2009).
>
> Such compatibility SHA-1 certificates typically have to chain to
> existing roots too (again because of relying party software
> limitations).
I would hope such issuance is occurring under technically constrained subCAs so
that a Flame-style chosen-prefix collision attack cannot result in a rogue
certificate that Mozilla would trust for TLS servers so long as Mozilla does not
disable SHA-1 certificates entirely.
>
>
> Enjoy
>
> Jakob
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
