On 26/02/14 12:45, Carl Wallace wrote:
On 2/26/14, 7:35 AM, "Rob Stradling" <[email protected]> wrote:
On 26/02/14 12:27, Ben Laurie wrote:
On 26 February 2014 11:57, Rob Stradling <[email protected]>
wrote:
<snip>
But if we must have ritual compliance with 5280, then my preferred
solution
is to "poison" the Issuer Name in the Precertificate.
For example...
Certificate Issuer Name: C=GB, O=My CA Ltd., CN=My CA
Precertificate Issuer Name: 1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA
Sign both the Precertificate and the Certificate with the same CA
private
key. Use the same serial number for both.
It wouldn't matter whether or not there exists a CA Certificate with
the
Subject Name "1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA".
Ah. I like that idea. Rather less than I like the idea of fixing the
need for ritual compliance, though.
+1
While I agree that lack of a CA certificate with the matching naming
really doesn¹t matter, breaking name chaining seems like an odd way to
maintain ³ritual compliance". Why not bump the version number instead?
v4 could be defined as a pre-certificate containing a poison extension and
a serial number that matches its v3 counterpart.
Hi Carl. I briefly discussed the idea of changing the version number
with Ben a few months ago...
Rob: "More wacky idea...
I wonder if we could get away with putting 0x4354 in the certificate's
Version field. That might be enough to place it out-of-scope of
RFC5280, and therefore out-of-scope of the duplicate serial number rule.
Probably more likely to break something though."
Ben: "I imagine it'd be hard to coerce most s/w to do this."
Also, I don't suppose IETF has the authority to define new X.509
versions anyway.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
