[cabfpub] Mozilla SHA-1 further restrictions

[Rob Stradling]

On 18/11/16 15:36, Gervase Markham wrote:
> On 18/11/16 15:27, Rob Stradling wrote:
>> See
>> https://tools.ietf.org/id/draft-ietf-trans-rfc6962-bis-20.html#rfc.section.3.2
>>
>> Does that make them "non-certificate data" ?
>
> I note the following in the RFC: "(Note that, because of the structure
> of CMS, the signature on the CMS object will not be a valid X.509v3
> signature and so cannot be used to construct a certificate from the
> precertificate)."
>
> Would one solution be to say that one condition on which signing
> non-cert data is OK is that if the signature is not a valid X.509v3
> signature? That would cover this case.

I think it would make more sense to tweak your definition of 
"certificate data" so that it includes precertificates.

Precertificates (in both RFC6962 and 6962-bis), like certificates, 
contain a TBSCertificate structure, which means that these things (from 
your v2 proposal) are relevant...

"1) The end-entity certificate:

   * is not within the scope of the Baseline Requirements;

   * contains an EKU extension with a single key purpose, which is not
     id-kp-serverAuth or anyExtendedKeyUsage;

   * has at least 64 bits of entropy from a CSPRNG in the serial number."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online