On 15/07/14 11:21, Ben Laurie wrote:
On 15 July 2014 06:15, Matt Palmer <[email protected]> wrote:
<snip>
As for exactly how it is signed, I don't have strong feelings about
that. Is there some appropriate RFC that specifies how to sign some
arbitrary binary blob using RSA or EC keys?
struct {
digitally-signed TBSCertificate;
opaque TBSCertificate<1..2^24-1>;
} Precertificate;
Hmm. That's a tempting thought!
"SIGNED", defined by X.509, is one of the ASN.1 ways to sign arbitrary
blobs. It's used for signing certificates, CRLs, CSRs, OCSP responses, etc.
RFC2459 expressed it as...
"SIGNED { ToBeSigned } ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithm AlgorithmIdentifier,
signature BIT STRING
}
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
..."
(However, for some reason RFC3280/5280 dropped "SIGNED" and changed the
certificate definition to...
"Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }")
We could define TBSPrecertificate as an ASN.1 structure that is very
similar to, but incompatible with, TBSCertificate. And then we could
define...
Precertificate ::= SIGNED { TBSPrecertificate }
An alternative ASN.1 way to sign arbitrary binary blobs is CMS
(originally called PKCS#7). See RFC5652.
A Precertificate could be a CMS object that uses the Signed-data content
type to carry a TBSCertificate.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
