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
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
