Subject: RE: Update request for RFC3279 and 4055

From: "Stevens, Frits" <[email-masked]>
Date: Fri, 4 May 2007 10:35:25 +0200

As one of the originators of this request to update rfc3279 and 4055 I
would like that the discussion is moved away from the attack
possiblities of SHA1.
In general SHA2 is meant to be used for building more secure
certificates. It is expected that by 2010 SHA1 should not be used
anymore for X.509 certificates. But, with the current rfc's it is not
possible to totally move away from SHA1. 
The current standards should be updated so that it will become possible
to create X.509 certificates that do not use SHA1 anymore for any
purpose. 
This is the only way to also convince the "normal" users that the
certificate in question is strong enough.   

--Frits Stevens 

-----Oorspronkelijk bericht-----
Van: Santosh Chokhani [mailto:[email-masked]]
Verzonden: donderdag 29 maart 2007 12:43
Aan: [email-masked]
Onderwerp: RE: Update request for RFC3279 and 4055

Because of the blanket statement about the security of the hash
algorithm.  It does matter that it be something akin to SHA1

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]
Sent: Wednesday, March 28, 2007 9:24 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Update request for RFC3279 and 4055

At 2:27 PM -0700 3/28/07, Santosh Chokhani wrote:
>I am concerned about the following statement: "As with the 
>fingerprint/thumbprint displayed by certificate viewers, the use of a 
>weak hash algorithm does not create any problems, security or 
>otherwise".
>
>Some PKIs find it acceptable to obtain a trust anchor using unsecure 
>means and verify that the fingerprint of the trust anchor matches the 
>fingerprint obtained via secure means.  For these users, hashing 
>algorithm used for fingerprint does become security relevant.
>
>(Granted that from what experts say, SHA-1 is not in an imminent danger

>of pre-image attack.  Pre-image attack is required in order to exploit 
>the trust anchor substitution in the above scenario)

This is confusing. If a pre-image attack is required in order to exploit
the trust anchor substitution, why are you concerned about the
statement?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 May 2007 09:49:02 -0700

>would like that the discussion is moved away from the attack

OK, but...

>anymore for X.509 certificates.

That is a false and dangerous expectation. Remember that Windows XP 
does not have any support for SHA2. In order for that expectation to 
be borne out, either Microsoft needs to add support for SHA2 
(something they have said many times they do not have intention to 
do), or everyone needs to move off of XP by 2010 (a belief that is 
delusuional, given that there are still double digit percentages of 
people using *earlier* OSs).

>But, with the current rfc's it is not

There is no need to change any standards to make that happen; they 
already fully allow it. Rajesh Lachman proposed that SHA2 be made an 
alternate SHOULD, which makes good sense. But it won't change 
anything in the real world until all verifiers can verify signatures 
with SHA2. Until then, a signer (particularly a CA) would be crazy to 
have it as part of their signature.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Fri, 04 May 2007 13:57:51 -0400

>to create X.509 certificates that do not use SHA1 anymore for any

I strongly advocate an orderly transition from SHA-1 to SHA-256, but 
I'm not sure I agree with the "for any purpose" part of your 
statement.  The use of SHA-1 in the computation of a key identifier 
would not bother me in the least.

Russ

---

From: "Stevens, Frits" <[email-masked]>
Date: Tue, 8 May 2007 11:25:23 +0200

The recently lounged RFC3280bis explicitly allows to use other
algorithms for AKI and SKI, but that's not the problem.

Only after applying the suggested update request to RFC3279 and RFC4055
it will become a requirement to use the same algorithm for both signing
and hashing.
I'm aware of the fact that XP currently is not supporting the
SHA2(signature) algorithm. We want them to implement SHA2 on those
platforms (200x/XP) as they already did on Vista but, without an update
to the above rfc's Microsoft (and other suppliers) they will never fix
this.

--Frits Stevens
--Getronics PinkRoccade   

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: vrijdag 4 mei 2007 18:49
To: Stevens, Frits; [email-masked]
Cc: Rajesh Lachman
Subject: RE: Update request for RFC3279 and 4055

OK, but...

>anymore for X.509 certificates.

That is a false and dangerous expectation. Remember that Windows XP does
not have any support for SHA2. In order for that expectation to be borne
out, either Microsoft needs to add support for SHA2 (something they have
said many times they do not have intention to do), or everyone needs to
move off of XP by 2010 (a belief that is delusuional, given that there
are still double digit percentages of people using *earlier* OSs).

There is no need to change any standards to make that happen; they
already fully allow it. Rajesh Lachman proposed that SHA2 be made an
alternate SHOULD, which makes good sense. But it won't change anything
in the real world until all verifiers can verify signatures with SHA2.
Until then, a signer (particularly a CA) would be crazy to have it as
part of their signature.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 8 May 2007 04:40:16 -0700

Fritz,

You miss the point.  As Russ Housley said, there is not a security
problem or issue in using SHA-1 for AKI and SKI since they are simply
efficiency filters in path development.  Collisions in AKI and SKI do
not lead to any security problems.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stevens, Frits
Sent: Tuesday, May 08, 2007 5:25 AM
To: Paul Hoffman; [email-masked]
Cc: Rajesh Lachman
Subject: RE: Update request for RFC3279 and 4055

--Frits Stevens
--Getronics PinkRoccade   

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: vrijdag 4 mei 2007 18:49
To: Stevens, Frits; [email-masked]
Cc: Rajesh Lachman
Subject: RE: Update request for RFC3279 and 4055

OK, but...

--Paul Hoffman, Director
--VPN Consortium

---

From: "Stevens, Frits" <[email-masked]>
Date: Wed, 9 May 2007 09:38:19 +0200

Santosh,

Correct, there is no problem with AKI or SKI. It's only an identifier
that needs to be unique within the doamin of the CA.
My point is that, when creating a certficate with SHA-2 as the signing
algorithm, the current standards only address the use of the SHA-1
hashing algorithm to create a message digest of the certificate content.

My request is that this should be updated to use the same (SHA-2:
sha-224, sha-256, etc.) algorithm for creating the message digest (shows
up as the fingerprint/thumbprint within a certificate view) as is used
for the signature. This is the only way to totally move away from the
SHA1 algorithm for both signing and verifying a certificate.
As long as these rfc's are not updated there is no way to fade-out
SHA-1, so we will wait forever to get this implemented.

Frits 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: dinsdag 8 mei 2007 13:40
To: [email-masked]
Subject: RE: Update request for RFC3279 and 4055

Fritz,

-----Original Message-----

--Frits Stevens
--Getronics PinkRoccade   

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]
Sent: vrijdag 4 mei 2007 18:49
To: Stevens, Frits; [email-masked]
Cc: Rajesh Lachman
Subject: RE: Update request for RFC3279 and 4055

OK, but...

--Paul Hoffman, Director
--VPN Consortium

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 9 May 2007 04:55:05 -0700

Fritz,

I am glad that we agree on AKI and SKI hashing being of no relevance
from security viewpoint.

Now, let us talk about hash (fingerprint) of the certificate.  Please
note that the fingerprint that is displayed is a different thing than
the "to-be-signed" hash of the certificate.  To-be-signed hash is the
content of the certificate without the signature that is signed and then
SIGNED MACRO adds the signature algorithm, parameters and signature.
(See the ASN.1 for precise details).

The fingerprint of the certificate is the hash of all the contents
including the SIGNED MACRO which contains signature, algorithm ID,
parameters, etc.

We have had the discussion on fingerprint of the certificate on this or
another thread in PKIX recently (within 1-2 months).

The fingerprint is only relevant for explicitly trusted certificates
such as self-signed roots.  It is relevant because the fingerprint
offers user friendly, out of band means to verify that the certificate
being explicitly trusted is the one you want to trust.  For these SHA-1
is acceptable since to defeat the security one requires pre-image attack
and that is not on the horizon even for SHA-1.

-----Original Message-----
Sent: Wednesday, May 09, 2007 3:38 AM

Santosh,

Frits 

-----Original Message-----

Fritz,

-----Original Message-----

--Frits Stevens
--Getronics PinkRoccade   

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]
Sent: vrijdag 4 mei 2007 18:49
To: Stevens, Frits; [email-masked]
Cc: Rajesh Lachman
Subject: RE: Update request for RFC3279 and 4055

OK, but...

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 May 2007 17:00:39 +0200

> and that is not on the horizon even for SHA-1.

I don't think SHA-1 is OK in the long run because if you can generate
two different CA certificates that have the same fingerprint, you'll
have problems.

Consider for example if one of the CA certs have some path restrictions
and the other doesn't.  Or if one of the CA cert specify that users must
use a particular insecure algorithm, and the other specify that they
must use a secure algorithm.

Creating two different CA certs whose SHA-1 hashes are the same is not
easy, but given the weaknesses in SHA-1 it may happen eventually.
Preparing for that possibility seems appropriate.

Btw, this problem is much more severe for PGP than it is for X.509.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 May 2007 07:59:59 -0700

>that needs to be unique within the doamin of the CA.

Glad that this is not an issue.

>hashing algorithm to create a message digest of the certificate content.

Correct.

>for the signature.

This seems like a gratuitous change. If there is no security problem 
with using SHA-1 for the identifier, changing it seems like making 
unnecessary work for no benefit.

>This is the only way to totally move away from the

At the time that we consider a MUST NOT for signing certificates with 
SHA-1, we can consider this as well. The chance of that is near zero. 
Note that we don't even have MUST NOTs for encrypting with 40-bit DES.

>SHA-1, so we will wait forever to get this implemented.

Correct.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 11 May 2007 21:36:15 -0400

Steven,

I made the same comment on 6/21/2006:

Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key 
id generation? How about striking SHA-1 from the methods and adding the 
new sentence to both: The hash algorithm employed can be the same 
algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256,
SHA-384).

The following was the editor's (David Cooper's) response  

Section 4.2.1.2 simply states that the two methods described are two common
methods for generating key identifiers.  The text explicitly does not
restrict CAs to using these methods. 

I can see his point as they are "Two common methods" and there are no
requirements to use either of the two choices.

spt

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stevens, Frits
> Correct, there is no problem with AKI or SKI. It's only an 
> identifier that needs to be unique within the doamin of the CA.
> My point is that, when creating a certficate with SHA-2 as 
> the signing algorithm, the current standards only address the 
> use of the SHA-1 hashing algorithm to create a message digest 
> of the certificate content.
> 
> sha-224, sha-256, etc.) algorithm for creating the message 
> digest (shows up as the fingerprint/thumbprint within a 
> certificate view) as is used for the signature. This is the 
> only way to totally move away from the
> As long as these rfc's are not updated there is no way to 
> fade-out SHA-1, so we will wait forever to get this implemented.
> 
> Frits 
>  
> 
> You miss the point.  As Russ Housley said, there is not a 
> security problem or issue in using SHA-1 for AKI and SKI 
> since they are simply efficiency filters in path development. 
>  Collisions in AKI and SKI do not lead to any security problems.
> 
> The recently lounged RFC3280bis explicitly allows to use 
> other algorithms for AKI and SKI, but that's not the problem.
> 
> Only after applying the suggested update request to RFC3279 
> and RFC4055 it will become a requirement to use the same 
> algorithm for both signing and hashing.
> SHA2(signature) algorithm. We want them to implement SHA2 on 
> those platforms (200x/XP) as they already did on Vista but, 
> without an update to the above rfc's Microsoft (and other 
> suppliers) they will never fix this.
> 
> --Frits Stevens
> --Getronics PinkRoccade   
> 
> That is a false and dangerous expectation. Remember that 
> Windows XP does not have any support for SHA2. In order for 
> that expectation to be borne out, either Microsoft needs to 
> add support for SHA2 (something they have said many times 
> they do not have intention to do), or everyone needs to move 
> off of XP by 2010 (a belief that is delusuional, given that 
> there are still double digit percentages of people using 
> *earlier* OSs).
> 
> There is no need to change any standards to make that happen; 
> they already fully allow it. Rajesh Lachman proposed that 
> SHA2 be made an alternate SHOULD, which makes good sense. But 
> it won't change anything in the real world until all 
> verifiers can verify signatures with SHA2.
> Until then, a signer (particularly a CA) would be crazy to

---

From: Dave Engberg <[email-masked]>
Date: Sat, 12 May 2007 17:44:48 -0400

If we were going to bother tinkering with AKI/SKI, I'd say it would be better to scrap both entirely.

In theory, AKI & SKI provide a small optimization for path discovery when a single named CA has several different public keys published in (non-expired) certs.  When the AKI+SKI matches, you can verify the EE cert's signature with the right CA key first instead of trying each key in order.

In practice, this optimization provides no value in the vast majority of cases when only one public key has been used by a named CA.  In the small number of cases where the same CA name has been used with multiple keys, relying parties are frequently given the "right" CA cert by the protocol (e.g. S/MIME, TLS, discrete AIAs).  If all else fails, the relying party can just try all of the CA's keys at a negligible performance cost (5-10ms per key on modern hardware).

This small performance optimization comes at a cost of 33 bytes per cert when SHA1 is used (double for intermediate CA certs).  Larger hash algorithms would increase this proportionately.  This overhead imposes fixed costs throughout the PKI, in the form of bandwidth, storage (e.g. space on smart cards, S/MIME mail storage), etc.

This is a classic computational speed vs. space trade-off which might have made sense when signature verification took a long time.  Nowadays, it doesn't really seem worth it to pay 33+ bytes/cert to save 10ms on a tiny fraction of path discovery operations.

From: Turner, Sean P.
Sent: Fri 5/11/2007 9:36 PM
To: Stevens, Frits; Santosh Chokhani; [email-masked]
Cc: Rajesh Lachman
Subject: RE: Update request for RFC3279 and 4055

Steven,

spt

> [mailto:[email-masked]]

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 14 May 2007 19:40:38 +0100

There is no interoperability issue here and no need to harmonize on a way to generate SKI/AKI.

What A CA does when issuing a CA certificate is in practice.
- Picks the SKI of its own current CA certificate and uses that as the AKI of any issued certificate.
- Generates a unique SKI for the issued certificate.

As long as the generated SKI is unique, it is OK. 2 separate CA:s does not need to apply the same algorithm.
As long as the probability for creating colliding SKI is sufficiently low, the algorithm is OK.

I'm totally convinced that SHA-1 is, and will forever be, sufficient for this purpose. Unless it will be so broken that a requester by selecting some valid key parameters can force an SKI collision which seems extremely unlikely. As attack it would also be totally useless as it at most would cause path building to be less effective, not to fail.

SKI/AKI is a useful tool to optimize path building. A match is however not required for a successful path.

I see no reason to update the standards on the issue of AKI/SKI generation.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: den 11 maj 2007 18:36
> To: 'Stevens, Frits'; 'Santosh Chokhani'; [email-masked]
> Cc: 'Rajesh Lachman'

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 14 May 2007 17:57:45 -0400

I agree with Stefan.

spt 

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Monday, May 14, 2007 2:41 PM
> To: [email-masked]; 'Stevens, Frits'; 'Santosh Chokhani'; 
> [email-masked]
> Cc: 'Rajesh Lachman'
> - Picks the SKI of its own current CA certificate and uses 
> that as the AKI of any issued certificate.
> As long as the generated SKI is unique, it is OK. 2 separate 
> CA:s does not need to apply the same algorithm.
> I'm totally convinced that SHA-1 is, and will forever be, 
> sufficient for this purpose. Unless it will be so broken that 
> a requester by selecting some valid key parameters can force 
> an SKI collision which seems extremely unlikely. As attack it 
> would also be totally useless as it at most would cause path 
> building to be less effective, not to fail.
> 
> SKI/AKI is a useful tool to optimize path building. A match 
> is however not required for a successful path.
> 
> > id generation? How about striking SHA-1 from the methods and adding 
> > the new sentence to both: The hash algorithm employed can 
> be the same 
> > Section 4.2.1.2 simply states that the two methods 
> described are two 
> > common methods for generating key identifiers.  The text explicitly 
> > does not restrict CAs to using these methods.
> >
> > > My point is that, when creating a certficate with SHA-2 as the 
> > > signing algorithm, the current standards only address the 
> use of the 
> > > SHA-1 hashing algorithm to create a message digest of the 
> > > certificate content.
> > >
> > > sha-224, sha-256, etc.) algorithm for creating the message digest 
> > > (shows up as the fingerprint/thumbprint within a 
> certificate view) 
> > > as is used for the signature. This is the only way to 
> totally move 
> > > away from the
> fade-out 
> security 
> > > problem or issue in using SHA-1 for AKI and SKI since they are 
> > > simply efficiency filters in path development.
> > > Only after applying the suggested update request to RFC3279 and 
> > > RFC4055 it will become a requirement to use the same 
> algorithm for 
> > > platforms (200x/XP) as they already did on Vista but, without an 
> > > update to the above rfc's Microsoft (and other
> Windows XP 
> > > >But, with the current rfc's it is not possible to 
> totally move away 
> > > >from SHA1.
> > > already fully allow it. Rajesh Lachman proposed that
> > > SHA2 be made an alternate SHOULD, which makes good sense. But it 
> > > won't change anything in the real world until all verifiers can 
> > > verify signatures with SHA2.
> > > Until then, a signer (particularly a CA) would be crazy 
> to have it 
> > > as part of their signature.
> > >
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > >
> > >
> > >
> > >
> >
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 14 May 2007 17:04:56 -0700

Stefan,

I agree with you on SHA-1.

I do not agree on the Issuing CA generating SKI for the Subject CA.  The
SKI in the Subject CA certificate should be the same as the AKI the
subject CA asserts in the certificates it issues.  If the AKI and SKI do
not chain, you might as well not use these extensions.

Also, note that when CAs cross certify, you can not say that a subject
CA can live at the whim of an issuing CA.  Actually, both the CAs, may
have already issued CA and/or end entity certificates asserting AKI.

The easiest way for the Issuing CA to ensure AKI/SKI chining is NOT to
generate SKI it wants to, but honor the SKI in P-10 request from the
subject CA.

There are error prone human intensive ways to do this, if you want to
pay more for your PKI operations and do not care if AKI/SKI chaining
error causes relying party software to be inefficient or outright reject
a valid path.

On a less important note, I do not like the connotation of "unique" SKI.
These values need to be probabilistically unique for a given CA and it
is better to not have a managed number (less management is better) to
create unique values.  But, may be that is not what you meant.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Monday, May 14, 2007 2:41 PM
To: [email-masked]; 'Stevens, Frits'; Santosh Chokhani;
[email-masked]
Cc: 'Rajesh Lachman'
Subject: RE: Update request for RFC3279 and 4055

There is no interoperability issue here and no need to harmonize on a
way to generate SKI/AKI.

What A CA does when issuing a CA certificate is in practice.
- Picks the SKI of its own current CA certificate and uses that as the
AKI of any issued certificate.
- Generates a unique SKI for the issued certificate.

As long as the generated SKI is unique, it is OK. 2 separate CA:s does
not need to apply the same algorithm.
As long as the probability for creating colliding SKI is sufficiently
low, the algorithm is OK.

I'm totally convinced that SHA-1 is, and will forever be, sufficient for
this purpose. Unless it will be so broken that a requester by selecting
some valid key parameters can force an SKI collision which seems
extremely unlikely. As attack it would also be totally useless as it at
most would cause path building to be less effective, not to fail.

SKI/AKI is a useful tool to optimize path building. A match is however
not required for a successful path.

I see no reason to update the standards on the issue of AKI/SKI
generation.

Stefan Santesson
Senior Program Manager

> id generation? How about striking SHA-1 from the methods and adding
the