Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt

From: [email-masked]
Date: Fri, 19 Aug 2016 05:30:23 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF.

        Title           : Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure 
        Authors         : Simon Josefsson
                          Jim Schaad
	Filename        : draft-ietf-curdle-pkix-01.txt
	Pages           : 15
	Date            : 2016-08-15

Abstract:
   This document specify algorithm identifiers and ASN.1 encoding
   formats for Elliptical Curve constructs using the Curve25519 and
   Curve448 curves.  The signature algorithms covered are Ed25519,
   Ed25519ph, Ed448 and Ed448ph.  The key agreement algorithm covered
   are X25519 and X448.  The Encoding for Public Key, Private Key and
   EdDSA digital signature structures is provided.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-curdle-pkix-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 Aug 2016 16:38:28 +0300

> 	Filename        : draft-ietf-curdle-pkix-01.txt

Did a brief look:

- The draft bans use of prehash variants for signing certificates and
  CRLs. What about OCSP responses?

IMO, basic cases:

                High value?   Large?
Certificates    Yes           No
OCSP            No            No
CRL             No            Maybe

So, prehashing probably shouldn't be allowed for certs, but
might be necressary for CRLs.

- Using intermediate objects (like I showed) would avoid having to
  support Ed25519ph/Ed448ph (where Ed25519ph can be especially
  problematic).

-Ilari

---

From: Jim Schaad <[email-masked]>
Date: Fri, 19 Aug 2016 09:59:16 -0700

> -----Original Message-----
> From: Curdle [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
> Sent: Friday, August 19, 2016 6:38 AM
> To: [email-masked]
> Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt
> 
> >         Title           : Algorithm Identifiers for Ed25519, Ed25519ph,
Ed448,
> Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key
Infrastructure
>   CRLs. What about OCSP responses?

Same paragraph in section 5 - although I said SHOULD NOT rather than MUST
NOT.
I am more than willing to increase this level.

> 
> IMO, basic cases:
> 
>                 High value?   Large?
> Certificates    Yes           No
> OCSP            No            No
> CRL             No            Maybe
> 
> So, prehashing probably shouldn't be allowed for certs, but might be
necressary
> for CRLs.

In many cases, the same key is being used to sign both certificates and CRLs
so it is probably easier to have the same level of badness for both
structures.

CRLs are never going to be streamed in and out which is where I find the
idea of doing hash then sign most attractive.  If people believe that CRLs
are going to be a problem, then the language would need to be something
along the lines of -- a different signing key is needed for CRLs if you do
the pre-hash case and client code needs to deal with large CRLs if that is
not what is being done.

I don't know how much current software is setup for delegated CRLs.

Jim

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 Aug 2016 20:07:49 +0300

> the pre-hash case and client code needs to deal with large CRLs if that is

Oh, the signed CRL structure is ASN.1 DER, which means it has length
field in the front, making streaming nasty?

(BTW: Added Ed448 support (Ed25519 was already in, albeit I needed to
adjust the OID) to one PKIX certificate verification code I am working
on).

-Ilari

---

From: Jim Schaad <[email-masked]>
Date: Fri, 19 Aug 2016 10:13:37 -0700

A new draft has been released which maps to the presentation that I gave in
Berlin.

Please review it to make sure that I got language correct, that I did not
miss anything really stupid.

There are a couple of things that I want to point out that were not in my
presentation:

1.  I make statements in section 5 on Certificates, CRLs, OCSP and AA
constructions.  We had talked about the implications for certificates but
not as much for the other constructs.  Are there other PKIX items that
should be included here.  Also, should this text be here in the key usage
bits section or in the next section?

2. On a suggestion from Russ I changed the title of the document.  It is
long, but complete.  Should we edit this down back to something smaller?

3.  I have changed the presentation so that each section talks about a
single structure.  I think this makes things easier to follow, however the
order could be changed if people thing it should be.

4.  I think that all of the examples are correct, however they all need to
be verified by a second person.  Volunteers are gladly accepted.

5.  I come from the world of S/MIME so people are going to find my ASN.1
module to be overly large in some respects.   I need to go back and verify
that I think the kaa-* items are correct based on the corresponding document
from Russ, but I think that I got them correct.  However people may object
to this and want to go back to the minimal ASN.1 module.

6.  The example certificate uses two different algorithms in it.  This means
it is not a self-signed certificate.  Do people want to move back to having
a different set of examples here?  We can easily expand this to add things
people thing are going to be useful.

Jim

> From: Curdle [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Friday, August 19, 2016 5:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt
> 
> 
Ed448, Ed448ph,
> X25519 and X448 for use in the Internet X.509 Public Key Infrastructure

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 22 Aug 2016 16:20:29 +0000

Bonjour,

> Le 19 août 2016 à 18:59, Jim Schaad <[email-masked]> a écrit :
> 
> 
> 

In some cases, and particularly in the WebPKI, the same key is used to sign certificates, CRLs, and OCSP responses. The size problem doesn’t really exist for OCSP responses.
Again, it’s not mandatory.

> the pre-hash case and client code needs to deal with large CRLs if that is

It’s not a question of streaming, but a question of HSM usage. I already found some HSMs crashing when sending a >32MB message for signature. Not that nice, but plausible.

> I don't know how much current software is setup for delegated CRLs.

Technically speaking, CRL delegation is a different beast.

Here, we could have either (1) a self-issued certificate dedicated for CRL signing, or (2) another CA certificate (attached to the same issuer as the existent one) dedicated for CRL signing. Rarely seen in practice.

Example of a (1)-type hierarchy:
Root (C=UT, O=Gov of Utopia, CN=Root CA)
  -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=keyCertSign, issued by Root)
    -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=crlSign, signed by the other key of CA1, whence self-issued)

Example of a (2)-type hierarchy:
Root (C=UT, O=Gov of Utopia, CN=Root CA)
  -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=keyCertSign, issued by Root)
  -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=crlSign, issued by Root)

Both are perfectly compliant with X.509 and RFC5280, but I don’t expect them to work out of the box. Rarely used, corner case, etc. As a guess exercise, I’d say that OpenSSL (1.0.1+) should be OK, Microsoft also, NSS may accept it depending on the validating lib (the old one should be OK, not the new one), and I wouldn’t bet on Apple. And from a CA’s perspective, that’s a weird gun pointed on their feet.

Cordialement,
Erwann Abalea

---

From: Jim Schaad <[email-masked]>
Date: Mon, 22 Aug 2016 11:50:16 -0700

> From: Curdle [mailto:[email-masked]] On Behalf Of Erwann Abalea
> Sent: Monday, August 22, 2016 9:20 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; Ilari Liusvaara <[email-masked]>
> >>> This draft is a work item of the CURves, Deprecating and a Little
> >>> more
> >> Encryption of the IETF.
> >>>
> > Same paragraph in section 5 - although I said SHOULD NOT rather than
> > MUST NOT.
> > In many cases, the same key is being used to sign both certificates
> > and CRLs so it is probably easier to have the same level of badness
> > for both structures.
> 
> In some cases, and particularly in the WebPKI, the same key is used to sign
> certificates, CRLs, and OCSP responses. The size problem doesn’t really exist for
> OCSP responses.
> > CRLs are never going to be streamed in and out which is where I find
> > the idea of doing hash then sign most attractive.  If people believe
> > that CRLs are going to be a problem, then the language would need to
> > be something along the lines of -- a different signing key is needed
> > for CRLs if you do the pre-hash case and client code needs to deal
> > with large CRLs if that is not what is being done.
> 
> It’s not a question of streaming, but a question of HSM usage. I already found
> some HSMs crashing when sending a >32MB message for signature. Not that
> nice, but plausible.

If I was worried about size, then I would encourage people to segment CRLs by the use of the CRLDistribution point rather than using a pre-hash version.  It seems that is already a problem for you since I doubt that the HSM you are looking at is doing EdDSA anyway.

> Technically speaking, CRL delegation is a different beast.

I don't see it as a different beast. It is a way to say that I am using two different keys.  One for certs and one for CRLs.  Since the general advice is don't use two different algorithms for the same private key this is needed if you want to prevent the pre-hash signature for certs and allow it for CRLs.

> 
> Here, we could have either (1) a self-issued certificate dedicated for CRL signing,
> or (2) another CA certificate (attached to the same issuer as the existent one)
> dedicated for CRL signing. Rarely seen in practice.
> 
>     -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=crlSign, signed by
> the other key of CA1, whence self-issued)
> 
> 
> Both are perfectly compliant with X.509 and RFC5280, but I don’t expect them
> to work out of the box. Rarely used, corner case, etc. As a guess exercise, I’d say
> that OpenSSL (1.0.1+) should be OK, Microsoft also, NSS may accept it
> depending on the validating lib (the old one should be OK, not the new one), and
> I wouldn’t bet on Apple. And from a CA’s perspective, that’s a weird gun pointed
> on their feet.

I don't understand which  weird gun you are referring to is.  The use of delegated CRLs?

Jim

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Aug 2016 09:05:04 +0000

Bonjour,

Le 22 août 2016 à 20:50, Jim Schaad <[email-masked]<mailto:[email-masked]>> a écrit :

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Erwann Abalea
Sent: Monday, August 22, 2016 9:20 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ilari Liusvaara <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt

Bonjour,

Le 19 août 2016 à 18:59, Jim Schaad <[email-masked]<mailto:[email-masked]>> a écrit :

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Ilari
Liusvaara
Sent: Friday, August 19, 2016 6:38 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt

On Fri, Aug 19, 2016 at 05:30:23AM -0700, [email-masked]<mailto:[email-masked]> wrote:

[…]

The problem was solved by doing the hash outside of the HSM, and requesting it to only perform the bare signature operation.

CRL delegation is more close to « indirect CRL » than having the same CA use different keys.

 -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=keyCertSign, issued
by Root)

Example of a (2)-type hierarchy:
Root (C=UT, O=Gov of Utopia, CN=Root CA)
 -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=keyCertSign, issued
by Root)
 -> CA 1 ("C=UT, O=Ministry of PKI, CN=Lab CA", keyUsage=crlSign, issued by
Root)

I’ve seen CAs (as organizations) failing to correctly renew+rekey a CA and produce good CRLs signed by the new key (it’s similar to the (2)-type hierarchy described). Renew a CA is seen as a standard operation, yet some fail to do so. Asking CA-orgs to setup more complicated stuff such as self-issued certs or multi-key CAs to do their job is unfriendly.

Cordialement,
Erwann Abalea

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 23 Aug 2016 10:14:37 -0400

Indirect CRL have inherent security problems and complexity.  You should avoid them if at all possible.

For reference to security concerns, see my presentation at IETF meeting to PKIX circa 2004 Fall in Washington DC or paper at NIST PKI research conference circa 2005 or 2006.

Sent: Tuesday, August 23, 2016 5:05 AM

Bonjour,

Le 22 août 2016 à 20:50, Jim Schaad <[email-masked] <mailto:[email-masked]> > a écrit :

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Erwann Abalea
Sent: Monday, August 22, 2016 9:20 AM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Ilari Liusvaara <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt

Bonjour,

Le 19 août 2016 à 18:59, Jim Schaad <[email-masked] <mailto:[email-masked]> > a écrit :

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Ilari
Liusvaara
Sent: Friday, August 19, 2016 6:38 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt

On Fri, Aug 19, 2016 at 05:30:23AM -0700, [email-masked] <mailto:[email-masked]>  wrote:

[…]

 

Cordialement,

Erwann Abalea

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Aug 2016 14:23:01 +0000

As co-chair:  So perhaps the question becomes:  how important is it that "jumbo" CRL's can be signed with these new algorithms?

As an individual:  since we don't even have certificates yet, not important.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Aug 2016 14:49:11 +0000

Is it good practice to specify a signature algorithm and declare that it can’t be used for you, you and you?

Cordialement,
Erwann Abalea

> Le 23 août 2016 à 16:23, Salz, Rich <[email-masked]> a écrit :
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Aug 2016 11:18:10 -0400

> As co-chair:  So perhaps the question becomes:  how important is it that "jumbo" CRL's can be signed with these new algorithms?

If we hope to see adoption in the Web PKI, then the answer is yes.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Aug 2016 15:26:23 +0000

> If we hope to see adoption in the Web PKI, then the answer is yes.

Perhaps my definition is off, but where are CRL's used in the webpki?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Aug 2016 15:27:35 +0000

> used for you, you and you?

I don't know if it's good practice, but it happens all the time with crypto algorithms.

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Aug 2016 11:39:33 -0400

> Perhaps my definition is off, but where are CRL's used in the webpki?

Mostly, OCSP Responders take the CRL as input to produce their cached OCSP Responses.

In S/MIME, which is not really a separate PKI, we see some mail user agent consume the CRL directly.

Russ

---

From: Brian Smith <[email-masked]>
Date: Tue, 23 Aug 2016 09:45:18 -1000

> If we hope to see adoption in the Web PKI, then the answer is yes.

The Web PKI in practice has already rejected the use of CRLs. We
shouldn't make things more complicated to support CRLs. We should
assume that internet protocols don't use CRLs, and let the users of
CRLs write their own RFCs to handle their special cases.

In particular, I think it is perfectly reasonable and good to require
("MUST") the non-prehash variant be used for certificate and OCSP
response signatures, and not say anything about CRLs at all. Another
draft could then specify a way to use these algorithms for CRLs.

The idea of "PKIX" was that certificates and certificate-related stuff
like OCSP, CRLs, ASN.1 decoding and encoding, etc. would work
uniformly across S/MIME, TLS, and whatever else uses PKIX stuff. That
idea has failed. Now we have to consider "Web PKI" and "the other
stuff" separately whenever we get into these details. In the Web PKI,
CRLs are dead. (Somebody should write an RFC to this effect.)

Cheers,
Brian

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Aug 2016 17:18:02 -0400

> CRLs are dead. (Somebody should write an RFC to this effect.)

I am going to try and avoid taking some of the bait you offer.  We actually seem to agree on more than we disagree.

I think it is quite reasonable to require ("MUST") the non-prehash variant of EdDSA for signatures, CRLs, and OCSP response.  The ASN.1 structures are the same, so why put the in different documents.

Russ

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 24 Aug 2016 09:51:37 +0000

Bonjour Brian,

> Le 23 août 2016 à 21:45, Brian Smith <[email-masked]> a écrit :
> 

Is the scope of draft WebPKI, or PKIX?
PKIX is used for things that aren’t necessarily web related, such as S/MIME, passports, contracts, code, ...

> draft could then specify a way to use these algorithms for CRLs.

That’s reasonable. Another way would be to define those signature algorithms, and let others decide if it’s reasonable to use them in their situation.
Just like defining RSA without key size or padding limitations, and let others decide if 1024 bits or RSAES-PKCS1 is acceptable or not, or if RSASSA-* with MD4 is suitable for a certificate in 2016. In some situations it’s an easy decision, but not always, and certainly not binary.

> idea has failed.

What has failed is expecting every object (CRL, OCSP, TST, …) to be equally useful in every situation where an X509 certificate can be used, without taking the context in account.

> Now we have to consider "Web PKI" and "the other

Amen.

Cordialement,
Erwann Abalea

---

From: Rob Stradling <[email-masked]>
Date: Wed, 24 Aug 2016 12:31:50 +0100

On 23/08/16 20:45, Brian Smith wrote:
> The Web PKI in practice has already rejected the use of CRLs.

Most of the main browsers have moved away from checking CRLs, but I 
think most of the CAs are still producing them.  (Let's Encrypt is the 
notable exception).

Browsers aren't/weren't the only consumers of CRLs.  CRLs are used 
behind the scenes: Russ already mentioned CRL-based OCSP responders; 
then there are the revocation aggregators such as Chrome's CRLSets.

> We shouldn't make things more complicated to support CRLs. We should

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