Subject: [therightkey] version -04 things to fix before/during IETF LC

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Dec 2012 09:50:20 +0000

Hiya,

- The "extensions [TBD]" line on p17 needs fixing before IETF LC
since that'd break/prevent interop.

- The [DSS] reference seems outdated, there's a version of fips 186
from 2009, I think you need to fix the reference text since the
1994 version is probably the wrong one at which to point. Best done
now but can be done after IETF LC.

- The poison extension: you say it has ASN.1 NULL data, but extensions
have OCTET STRING syntax. Do you mean an ASN.1 NULL (0x05 0x00) is
encoded as the value of the OCTET STRING or that the OCTET STRING
has zero length? This can be fixed after IETF LC, or now, if you
know what you're code does, but needs fixing.

- Having a thing with basicConstraints.cA==false issue precerts
seems wrong, but that may be better discussed during IETF LC so
I'm not requesting a change now.

So only the first need hold up IETF LC but the next two might
be worth fixing since a -05 is needed anyway. Not sure about the
last one, probably best to review during IETF LC.

Cheers,
S.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 11:20:09 +0000

> I'm not requesting a change now.

This was deliberate to avoid the precertificate being a valid
certificate, as requested by CAs.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Dec 2012 11:26:00 +0000

On 12/20/2012 11:20 AM, Ben Laurie wrote:
> This was deliberate to avoid the precertificate being a 

Well it avoids the precert issuer being a CA. The precert is
still syntactically a cert. And you need to use the precert
issuer private key to make a precert. Some s/w might refuse
if it saw that cert for the precert issuer that has .cA==false.

No reason why you can't make it happen in principle, but
I've no idea if needing s/w like that'd be a real barrier
or not.

S.

> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>

---

From: Rob Stradling <[email-masked]>
Date: Thu, 20 Dec 2012 11:28:21 +0000

> certificate, as requested by CAs.

Ben, doesn't the new poison critical extension requirement mean that 
this Basic Constraints hack is no longer needed?

The poison critical extension means that a precert cannot be used as a 
cert.  Is that not invalid enough?!?

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 11:38:06 +0000

> if it saw that cert for the precert issuer that has .cA==false.

I missed out the word "valid", sorry. And you are correct that it
might be a problem for software. Emilia and I have already debated
removing it - how about I may it a MAY?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 11:38:45 +0000

On 20 December 2012 11:28, Rob Stradling <[email-masked]> wrote:
> Ben, doesn't the new poison critical extension requirement mean that this
> Basic Constraints hack is no longer needed?
>
> The poison critical extension means that a precert cannot be used as a cert.
> Is that not invalid enough?!?

Probably.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 11:39:48 +0000

>> Is that not invalid enough?!?

I've removed it.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 11:41:25 +0000

> know what you're code does, but needs fixing.

Extensions have OCTET STRING containing valid DER syntax :-)

We mean what we say: ASN.1 NULL data.

What would you like us to fix?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Dec 2012 11:48:03 +0000

> What would you like us to fix?

Explicitly say that the ASN.1 NULL (0x05 0x00) is the
value of the OCTET STRING. People have gotten NULL messed up
before like that, mainly in AlgorithmIdentifier, but quite
a few did it. They assumed because it said "NULL" that meant
that nothing is put into the DER encoding. That breaks
interop.

Now in this case, since you're trying to deliberately break
interop for those precerts you could defend the ambiguity
I guess, but it makes me hold my nose even so;-)

S.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 20 Dec 2012 12:02:17 +0000

On 20/12/12 11:48, Stephen Farrell wrote:
<snip>
> that nothing is put into the DER encoding. That breaks

In case it helps...

I just looked at RFC5280 and its predecessors for inspiration on how 
best to specify the syntax of certificate extensions.

RFC2459 says stuff like...

id-ce-basicConstraints             OBJECT IDENTIFIER ::= {id-ce 19}

basicConstraints EXTENSION ::= {
         SYNTAX  BasicConstraintsSyntax
         IDENTIFIED BY id-ce-basicConstraints }

BasicConstraintsSyntax ::= SEQUENCE {
         cA                      BOOLEAN DEFAULT FALSE,
         pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

...but RFC3280 and RFC5280 replaced the EXTENSION definitions with 
comments...

-- basic constraints extension OID and syntax

id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }

BasicConstraints ::= SEQUENCE {
      cA                      BOOLEAN DEFAULT FALSE,
      pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

---

From: Rob Stradling <[email-masked]>
Date: Thu, 20 Dec 2012 14:06:53 +0000

>>> Is that not invalid enough?!?

Ben, I see that "(note that the log may relax standard validation rules 
to allow this, so long as the final signed certificate will be valid)" 
is still present in -05.  I think I see why...

Am I correct that the Issuer and Authority Key Identifier fields in a 
precertificate MUST match the Subject and Subject Key Identifier fields 
in "the CA certificate that will sign the final certificate", even if 
the precertificate is actually signed by the private key that 
corresponds to a Precertificate Signing Certificate?

If yes, then I think it might be worth emphasizing this point.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 14:49:56 +0000

On 20 December 2012 14:06, Rob Stradling <[email-masked]> wrote:
>>>> this
> Ben, I see that "(note that the log may relax standard validation rules to
> allow this, so long as the final signed certificate will be valid)" is still
> present in -05.  I think I see why...
>
> precertificate MUST match the Subject and Subject Key Identifier fields in
> "the CA certificate that will sign the final certificate", even if the
> precertificate is actually signed by the private key that corresponds to a
> Precertificate Signing Certificate?
>

Right now the log actually replaces these with the right things,
rather than requiring the pre-cert to contain them. But again, we are
happy to be guided by CAs on the best thing to do here.

The reason for that note was actually for things like path length
constraints that might get violated by inserting an extra
intermediate.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Dec 2012 11:27:18 +0000

On 20/12/12 14:49, Ben Laurie wrote:
<snip>
> constraints that might get violated by inserting an extra

Ah, I see.  I'll be using the "CA certificate that will sign the final 
certificate" option when I implement this for Comodo, so I don't really 
have any opinions on what "the best thing to do here" is.

If any CAs intend to use Precertificate Signing Certificates but are 
unable to tweak their CA software to "relax standard validation rules", 
then they should speak up now!