Subject: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4

From: Russ Housley <[email-masked]>
Date: Fri, 18 Dec 2020 09:55:51 -0500

What should we do here?

> From: "Marian Ďurkovič" <[email-masked]>
> Subject: Conflict between RFC8954 and ISO 14533-4
> Date: December 18, 2020 at 5:40:13 AM EST
> To: [email-masked]
> 
> Dear Russ,
> 
> I'd like to notify you about conflict between recently published RFC8954 and ISO 14533-4:2019 standard.
> 
> According to ISO 14533-4:2019, OCSP's Nonce extension is used to transmit MessageImprint field according to RFC3161 in order to be able to link OCSP response to a specific digital signature. With e.g. SHA512 algorithm, that definitely means much more than 32 bytes, as mentioned in RFC8954. 
> 
> Therefore it's necessary to significantly increase the maxbytes limit for OCSP Nonce, to e.g. 128 bytes. Otherwise it won't be possible to support usage intended in ISO 14533-4:2019
> 
> 
> With kind regards,
> MD
>

---

From: Mohit Sahni <[email-masked]>
Date: Fri, 18 Dec 2020 10:39:44 -0800

Hi Russ
RFC 6960 states that the purpose of OCSP nonce extension is to avoid replay
attacks and as per Marian I see that ISO 14533-4:2019 is not using the OCSP
Nonce extension for that purpose. I tried getting a copy of ISO
14533-4:2019 but it is behind a paywall. In my opinion, since the server is
not guaranteed to return the Nonce in the OCSP response, this standard
already has issues unless both OCSP client and responder agree to the
standard. If that is the case, then they should have used a custom
extension for this purpose instead of piggybacking on the OCSP Nonce
extension.

My response is based on the information provided by Marian regarding
the ISO 14533-4:2019. If it is permitted and someone can share the section
of the standard regarding OCSP nonce usage that would be appreciated.

Thanks
Mohit

On Fri, Dec 18, 2020 at 6:56 AM Russ Housley <[email-masked]> wrote:

> What should we do here?
>
>
> *From: *"Marian Ďurkovič" <[email-masked]>
> *Subject: **Conflict between RFC8954 and ISO 14533-4*
> *Date: *December 18, 2020 at 5:40:13 AM EST
> *To: [email-masked]
>
> Dear Russ,
>
> According to ISO 14533-4:2019, OCSP's Nonce extension is used to transmit
> MessageImprint field according to RFC3161 in order to be able to link OCSP
> response to a specific digital signature. With e.g. SHA512 algorithm, that
> definitely means much more than 32 bytes, as mentioned in RFC8954.
>
> Therefore it's necessary to significantly increase the maxbytes limit for
> OCSP Nonce, to e.g. 128 bytes. Otherwise it won't be possible to support
> usage intended in ISO 14533-4:2019
>
>
> With kind regards,
> MD
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Dec 2020 15:00:45 -0500

Mohit:

I was only able to see the information sections of ISO 14533-4:2019 on the website, and those sections do not tell enough to determine anything further.

I was completely unaware of anyone placing anything other than a random value in the OCSP nonce field before this message arrived today.  Does anyone know of other situations like this?

Russ

> On Dec 18, 2020, at 1:39 PM, Mohit Sahni <[email-masked]> wrote:
> 
> Hi Russ
> RFC 6960 states that the purpose of OCSP nonce extension is to avoid replay attacks and as per Marian I see that ISO 14533-4:2019 is not using the OCSP Nonce extension for that purpose. I tried getting a copy of ISO 14533-4:2019 but it is behind a paywall. In my opinion, since the server is not guaranteed to return the Nonce in the OCSP response, this standard already has issues unless both OCSP client and responder agree to the standard. If that is the case, then they should have used a custom extension for this purpose instead of piggybacking on the OCSP Nonce extension. 
> 
> My response is based on the information provided by Marian regarding the ISO 14533-4:2019. If it is permitted and someone can share the section of the standard regarding OCSP nonce usage that would be appreciated.
> 
> Thanks
> Mohit 
> 
> On Fri, Dec 18, 2020 at 6:56 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> What should we do here?
> 
> 
>> From: "Marian Ďurkovič" <[email-masked] <mailto:[email-masked]>>
>> To: [email-masked] <mailto:[email-masked]>
>> 
>> Dear Russ,
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Dec 2020 20:30:08 +0000

*   I was completely unaware of anyone placing anything other than a random value in the OCSP nonce field before this message arrived today.  Does anyone know of other situations like this?

In the early days of designing OCSP, CertCo and its member banks were going to put the digest of an online message in there, as a way of showing that the message was signed by an entity whose certificate was valid at the time of signing.  (Some scant details at https://en.wikipedia.org/wiki/CertCo_(financial_services) )   When CertCo folded, so did that concept I think.

The ISO folks could put a digest of the identifier as the nonce, or they could have a profile that says RFC8954 does not apply.

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Dec 2020 15:51:37 -0500

Rich:

> In the early days of designing OCSP, CertCo and its member banks were going to put the digest of an online message in there, as a way of showing that the message was signed by an entity whose certificate was valid at the time of signing.  (Some scant details at https://en.wikipedia.org/wiki/CertCo_(financial_services) <https://en.wikipedia.org/wiki/CertCo_(financial_services)> )   When CertCo folded, so did that concept I think.
>  

I think that more and more libraries will enforce the size constraint.

For example, in pyasn1, the following defines Nonce from RFC 8984:

	class Nonce(univ.OctetString):
	    subtypeSpec = constraint.ValueSizeConstraint(1, 32)

If a nonce longer than 32 octets is provided, a decode error will result.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Dec 2020 20:53:06 +0000

To be very clear: I am in favor of the constraints, and pointed out two ways ISO 14533 could handle it.  I do not think we need to do anything.

  *   The ISO folks could put a digest of the identifier as the nonce, or they could have a profile that says RFC8954 does not apply.

---

From: Mohit Sahni <[email-masked]>
Date: Fri, 18 Dec 2020 15:05:41 -0800

Hi Marian,
So in this case does OCSP responder fill the Nonce extension with its own
data and does not echo back what OCSP client has sent or I am missing
something ? Can you please provide more details on the use case.

-Mohit

On Fri, Dec 18, 2020 at 2:59 PM Marian Ďurkovič <[email-masked]> wrote:

> *On Fri, 18 Dec 2020 20:30:08 +0000, Salz, Rich wrote*
>
>    - I was completely unaware of anyone placing anything other than a
>    random value in the OCSP nonce field before this message arrived today.
>    Does anyone know of other situations like this?
>
> > In the early days of designing OCSP, CertCo and its member banks were
> going to put the digest of an online message in there, as a way of showing
> that the message was signed by an entity whose certificate was valid at the
> time of signing.  (Some scant details at
> https://en.wikipedia.org/wiki/CertCo_(financial_services) )   When CertCo
> folded, so did that concept I think.
>
> This is very similar - MessageImprint of a digital signature is placed
> into Nonce as a proof, that this digital signature existed at Production
> Time of OSCP response, which also means the certificate was valid at the
> time of signing
>
> > The ISO folks could put a digest of the identifier as the nonce, or they
> could have a profile that says RFC8954 does not apply.
>
> I'm afraid none of the above will work.
>
> According to RFC3161, Message imprint is defined as:
>
> MessageImprint ::= SEQUENCE  {
>      hashAlgorithm                AlgorithmIdentifier,
>      hashedMessage                OCTET STRING  }
>
>
> Since you need 19 bytes for the structure and AlgorithmIdentifier, with a
> 32 byte limit imposed on Nonce you'll only have 13 bytes left, which is too
> few even for legacy & no longer secure algorithms like MD5 or SHA1. And
> when libraries implement 32 byte limit, anything else will require
> customized libraries...
>
> For SHA256, you'll need room for at least 19+32=51 bytes in Nonce
> For SHA512, you'll need room for at least 19+64=83 bytes in Nonce.
>
> That's why I propose to increase limit from 32 to 128 bytes, which will
> keep some extra bytes for the future or for other purposes. This will keep
> all benefits of having a limit in place and at the same time allow Nonce to
> be used for additional purposes.
>
> With kind regards,
> MD
>
>

---

From: Mohit Sahni <[email-masked]>
Date: Fri, 18 Dec 2020 17:02:45 -0800

Hi Marian
I did some internet search and I found out a document that explains the ISO
14533, (https://www.bsmi.gov.tw/wSite/public/Data/f1415951364236.pdf). I
think the OCSP Nonce extension is being used by ISO 14533 in a way that it
was not intended to be used for.
If my understanding is correct, then the OCSP response also goes as part of
the digitally signed document along with the signature and the timestamp of
the signature and the application verifying the signature will look at the
OCSP Nonce and match it with the signature's imprint to make sure the OCSP
response is for the particular document that has signature.

Since servers can choose not to echo back the OCSP Nonce extension, in that
case the document validator cannot validate this assertion that the status
of the certificate was not revoked at the time of signing the document.

In my opinion we should have a new OCSP (and may be CRL) extension to
support the long term validation of OCSP status. I.e. linking the OCSP
response with the signed data and leave Nonce extension as it is to prevent
replay attacks. If everyone agree I am happy to write a draft for that.

Thanks,
Mohit

On Fri, Dec 18, 2020 at 3:19 PM Marian Ďurkovič <[email-masked]> wrote:

> *On Fri, 18 Dec 2020 15:05:41 -0800, Mohit Sahni wrote*
> > So in this case does OCSP responder fill the Nonce extension with its
> own data and does not echo back what OCSP client has sent or I am missing
> No, the proof of existence for the signature relies on the fact, that OCSP
> responder echoes back exactly what it received from the OCSP client, so no
> special functionality is needed.
>
> The process looks like this:
>
> - signing application prepares the digital signature and puts its imprint
> into Nonce field of OCSP request
> - OCSP response will contain proof of certificate's validity, trusted
> ProductionTime and echoed Nonce from the request, linking it to exactly
> this digital signature
>
> With kind regards,
> MD
>
>

---

From: Mohit Sahni <[email-masked]>
Date: Sat, 19 Dec 2020 03:05:32 -0800

Hi Marian,
I am sorry, I don't concur with you on this matter. The use case mentioned
in ISO 14533 is somewhat analogous to the AEAD in symmetric
encryption/decryption. According to the ISO 14533 we are binding the OCSP
response with the event of the digital signature generated by a particular
private key and then bundling the OCSP response with the digital signature
to prove that the status of the key was not revoked at the time of
generating the signature.

On the contrary the purpose of Nonce extension is to prevent replay attacks
and as discussed in the LAMPS WG the value must be generated using a
cryptographically strong random number. I don't think it is a good idea to
repurpose an extension for some other function when we are talking about
the security. What if someone replays a valid OCSP response after the key
has been revoked by guessing the MessageImprint ?

You are quoting the nonce of RFC3161 out of the context here and it is not
relevant to this discussion for OCSP. However even RFC3161 mentions in
section 2.4.1 that the nonce value should be a large random integer with a
suggested size of 64-bit to avoid the replay of the response to TimeStampReq.

I will agree with what Rich said in an earlier email.

Thanks
Mohit

On Sat, Dec 19, 2020 at 1:42 AM Marian Ďurkovič <[email-masked]> wrote:

> *On Fri, 18 Dec 2020 17:02:45 -0800, Mohit Sahni wrote*
>  > If my understanding is correct, then the OCSP response also goes as
> part of the digitally signed document along with the signature and the
> timestamp of the signature and the application verifying the signature will
> look at the OCSP Nonce and match it with the signature's imprint to make
> sure the OCSP response is for the particular document that has signature.
>
> Yes, with a note that a document could contain several signatures. Nonce
> matches the OCSP response to one specific signature.
>
> Introducing a new extension will create serious operational issues, since:
>
> - it'll require update of all OCSP responders
> - it'll require update of all signing applications
> - in order not to invalidate existing signatures, dual validation will
> have to be performed (both with Nonce and with the new extension)
>
> Please note, that Nonce extension according to RFC2560 and RFC6960
> supported all required functionality, the problem was introduced only by
> RFC8954, which set the limit of usable bytes too low.
>
> Thus I propose to only make errata to RFC8954, since the current text will
> cause implementation/deployment problems for digital signatures.
>
> This errata could increase the limit from 32 bytes to some higher value:
>
> - if size of OCSP responses is of highest concern, value of 96 bytes would
> be fine for 512 bit hashes like SHA512
> - if the limit should be sufficient for eventual future algorithms with
> 1024 bit hashes, value of 160 can be used.
>
> Reason for errata: Nonce extension is used to carry MessageImprint
> according to RFC3161 in order to link digital signature to OCSP response.
>
>
> With kind regards,
> MD
>

---

From: "Marian Ďurkovič" <[email-masked]>
Date: Fri, 18 Dec 2020 23:59:50 +0100

On Fri, 18 Dec 2020 20:30:08 +0000, Salz, Rich wrote

I was completely unaware of anyone placing anything other than a random value in the OCSP nonce field before this message arrived today.  Does anyone know of other situations likethis?

> In the early days of designing OCSP, CertCo and its member banks were going to put the digest of an online message in there, as a way of showing that the message was signed by an entity whose certi…

This is very similar - MessageImprint of a digital signature is placed into Nonce as a proof, that this digital signature existed at Production Time of OSCP response, which also means the certificate was valid at the time of signing

Since you need 19 bytes for the structure and AlgorithmIdentifier, with a 32 byte limit imposed on Nonce you'll only have 13 bytes left, which is too few even for legacy & no longer secure algorithms like MD5 or SHA1. And when libraries implement 32 byte limit, anything else will require customized libraries...

That's why I propose to increase limit from 32 to 128 bytes, which will keep some extra bytes for the future or for other purposes. This will keep all benefits of having a limit in place and at the same time allow Nonce to be used for additional purposes.

With kind regards,

MD

---

From: "Marian Ďurkovič" <[email-masked]>
Date: Sat, 19 Dec 2020 00:19:40 +0100

On Fri, 18 Dec 2020 15:05:41 -0800, Mohit Sahni wrote

> So in this case does OCSP responder fill the Nonce extension with its own data and does not echo back what OCSP client has sent or I am missing something ? Can you please provide more details on the use case. 

No, the proof of existence for the signature relies on the fact, that OCSP responder echoes back exactly what it received from the OCSP client, so no special functionality is needed.

- signing application prepares the digital signature and puts its imprint into Nonce field of OCSP request

- OCSP response will contain proof of certificate's validity, trusted ProductionTime and echoed Nonce from the request, linking it to exactly this digital signature

With kind regards,

MD

---

From: "Marian Ďurkovič" <[email-masked]>
Date: Sat, 19 Dec 2020 10:42:56 +0100

On Fri, 18 Dec 2020 17:02:45 -0800, Mohit Sahni wrote

 > If my understanding is correct, then the OCSP response also goes as part of the digitally signed document along with the signature and the timestamp of the signature and the application verifying the signature will look at the OCSP Nonce and match it with the signature's imprint to make sure the OCSP response is for the particular document that has signature.

Yes, with a note that a document could contain several signatures. Nonce matches the OCSP response to one specific signature.

> In my opinion we should have a new OCSP (and may be CRL) extension to support the long term validation of OCSP status. I.e. linking the OCSP response with the signed data and leave Nonce extension as it is to prevent replay attacks. If everyone agree I am happy to write a draft for that.

- in order not to invalidate existing signatures, dual validation will have to be performed (both with Nonce and with the new extension)

Please note, that Nonce extension according to RFC2560 and RFC6960 supported all required functionality, the problem was introduced only by RFC8954, which set the limit of usable bytes too low.

Thus I propose to only make errata to RFC8954, since the current text will cause implementation/deployment problems for digital signatures.

- if size of OCSP responses is of highest concern, value of 96 bytes would be fine for 512 bit hashes like SHA512

- if the limit should be sufficient for eventual future algorithms with 1024 bit hashes, value of 160 can be used.

Reason for errata: Nonceextension is used to carry MessageImprint according to RFC3161 in order to link digital signature to OCSP response.

With kind regards,

MD

---

From: "Marian Ďurkovič" <[email-masked]>
Date: Sat, 19 Dec 2020 13:50:29 +0100

On Sat, 19 Dec 2020 03:05:32 -0800, Mohit Sahni wrote

> On the contrary the purpose of Nonce extension is to prevent replay attacks and as discussed in the LAMPS WG the value must be generated using a cryptographically strong random number. I don't think it is a good idea to repurpose an extension for some other function when we are talking about the security. What if someone replays a valid OCSP response after the key has been revoked by guessing the MessageImprint ? 

This OSCP response is only usable for specific signer of a specific document signed at specific time. All these inputs are hashed by at least SHA256, signed by signer's private key and the resulting signature is again hashed by at least SHA256 to get MessageImprint, which is inserted into Nonce - so its randomnes is ensured. Could you please elaborate, how are you able to guess this kind of Nonce? If that would be possible, we won't be able to trust any digital signature, since the same procedure is being used for Timestamp tokens!

By filling Nonce with MessageImprint, the signing application is generating 32 (for SHA256) or 64 (for SHA512) highly random bytes. This kind of Nonce thus serves both purposes - ensures security against replay attacks and provides trusted binding between the specific signature in specific document and associated OCSP response. The only real problem is, that RFC8954 set the max bytes limit too low and there's hardly any good reason why it couldn't be increased from 32 to e.g. 96 bytes.

With kind regards,

MD

---

From: Mohit Sahni <[email-masked]>
Date: Sat, 19 Dec 2020 13:12:17 -0800

Hi Marian
>From OCSP point of view the MessageImprint is not a random value but it is
a deterministic value generated for a given input by a collision resistant
one way hash function. One more reason I see for not changing the Nonce
extension length is that the length of MessageImprint is not fixed but
varies based on the underlying hash algorithm.  Since RFC3161 does not
provide a fixed list of Hash functions, let's say we change the size to
Nonce extension to 64 bytes, what if in the future there is a new hash
algorithm or some proprietary hash function that requires size to be 128
bytes or 256 bytes or may be 100 GigaBytes, are we going to increase the
size of the Nonce extension again?  How can we set an upper limit on Nonce
which also serves the regular Nonce use case of just avoiding the replay
attacks ?

In my opinion, ISO 14533 took advantage of the security vulnerability that
existed in RFC6960 and tried using Nonce extension in a way it was not
intended to be used as i.e. using an ASN.1 SEQUENCE where the standard
requires use of OCTET STRING. We should come up with a new extension for
associating the OCSP response with the context where OCSP is being used for
long term validation. That is the right thing to do.

-Mohit

On Sat, Dec 19, 2020 at 4:50 AM Marian Ďurkovič <[email-masked]> wrote:

> *On Sat, 19 Dec 2020 03:05:32 -0800, Mohit Sahni wrote*
> > On the contrary the purpose of Nonce extension is to prevent
> replay attacks and as discussed in the LAMPS WG the value must be generated
> using a cryptographically strong random number. I don't think it is a good
> idea to repurpose an extension for some other function when we are talking
> about the security. What if someone replays a valid OCSP response after the
> key has been revoked by guessing the MessageImprint ?
>
> This OSCP response is only usable for specific signer of a specific
> document signed at specific time. All these inputs are hashed by at least
> SHA256, signed by signer's private key and the resulting signature is again
> hashed by at least SHA256 to get MessageImprint, which is inserted into
> Nonce - so its randomnes is ensured. Could you please elaborate, how are
> you able to guess this kind of Nonce? If that would be possible, we won't
> be able to trust any digital signature, since the same procedure is being
> used for Timestamp tokens!
>
> By filling Nonce with MessageImprint, the signing application is
> generating 32 (for SHA256) or 64 (for SHA512) highly random bytes. This
> kind of Nonce thus serves both purposes - ensures security against replay
> attacks and provides trusted binding between the specific signature in
> specific document and associated OCSP response. The only real problem is,
> that RFC8954 set the max bytes limit too low and there's hardly any good
> reason why it couldn't be increased from 32 to e.g. 96 bytes.
>
> With kind regards,
> MD
>

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 21 Dec 2020 09:43:33 -0800

HI Marian
I have shared my point of view on this and I will let others weigh in.

One correction to your last comment
>And what will be the advantage of having yet another extension doing the
same thing? Both use cases require nothing else from OCSP responder than to
echo back exactly the same bytes it received in request. Do you propose to
have 2 extensions, one of them being able to only echo 32 bytes and another
being able to echo 96? or 160? or unlimited bytes? Isn't it much more
straightforward to have only one "echoing" extension being able to echo as
many bytes as needed for both use cases?

OCSP Responder is not required to echo the Nonce extension value even if it
supports the extension and it can send a Nonce back to client even if it
did not receive one in the OCSP request (Section 4 RFC5019). So if ISO
14533-4 requires the MessageImprint in the OCSP response for the long term
validation, then it is already broken there. The new extension can make
sure if Responder supports it then MUST echo back.

-Mohit

On Mon, Dec 21, 2020 at 8:36 AM Marian Ďurkovič <[email-masked]> wrote:

> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
> > From OCSP point of view the MessageImprint is not a random value but it
> is a deterministic value generated for a given input by a collision
> resistant one way hash function.
>
> This input, however, consists of multiple parts: some of them being
> random, some of them being unknown even to document signer (private key).
> In any case, an attacker is not able to guess this value so it serves
> against reply attack very well.
>
> > One more reason I see for not changing the Nonce extension length is
> that the length of MessageImprint is not fixed but varies based on the
> underlying hash algorithm.  Since RFC3161 does not provide a fixed list of
> Hash functions, let's say we change the size to Nonce extension to 64
> bytes, what if in the future there is a new hash algorithm or some
> proprietary hash function that requires size to be 128 bytes or 256 bytes
> or may be 100 GigaBytes, are we going to increase the size of the Nonce
> extension again?  How can we set an upper limit on Nonce which also serves
> the regular Nonce use case of just avoiding the replay attacks ?
>
> I proposed 2 values: 96 bytes if we want to accomodate 512-bit hashes, or
> 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any hashing
> algorithm is designed to yield a relatively small result, so we're
> certainly not talking about GigaBytes here...
>
> > In my opinion, ISO 14533 took advantage of the security vulnerability
> that existed in RFC6960 and tried using Nonce extension in a way it was not
> requires use of OCTET STRING.
>
> OCTET STRING means arbitrary sequence of bytes, which OCSP responder
> shouldn't interpret in any way - just echo them back in its response. It's
> completely irrelevant, what's encoded inside - after all, a random number
> could also start with 0x30 which corresponds to SEQUENCE.
>
> > We should come up with a new extension for associating the OCSP response
> with the context where OCSP is being used for long term validation. That is
> the right thing to do.
>
> And what will be the advantage of having yet another extension doing the
> same thing? Both use cases require nothing else from OCSP responder than to
> echo back exactly the same bytes it received in request. Do you propose to
> have 2 extensions, one of them being able to only echo 32 bytes and another
> being able to echo 96? or 160? or unlimited bytes? Isn't it much more
> straightforward to have only one "echoing" extension being able to echo as
> many bytes as needed for both use cases?
>
> On the other hand, the disadvantages are significant - I mentioned some of
> them in my previous email. Also please keep in mind, that RFC 8954 (if
> applied by OCSP responder or by some firewall doing deep packet inspection)
> will immediately break digital signing - since it says:
>
>    A server *MUST* reject any OCSP request that has a nonce in the Nonce
>    extension with a length of either 0 octets or more than 32 octets
>    with the malformedRequest OCSPResponseStatus
>
> Last but not least, introducing another extension is more complex than you
> assume - it will require modification of (at least) RFC6960, RFC5019, ISO
> 14533-4. When will that solution be available and what to do until then?
>
> With kind regards,
> MD
>
>
>
>

---

From: "Marian Ďurkovič" <[email-masked]>
Date: Mon, 21 Dec 2020 17:36:46 +0100

On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote

> From OCSP point of view the MessageImprint is not a random value but it is a deterministic value generated for a given input by a collision resistant one way hash function.

This input, however, consists of multiple parts: some of them being random, some of them being unknown even to document signer (private key). In any case, an attacker is not able to guess this value so it serves against reply attack very well.

> One more reason I see for not changing the Nonce extension length is that the length of MessageImprint is not fixed but varies based on the underlying hash algorithm.  Since RFC3161 does not provide a fixed list of Hash functions, let's say we change the size to Nonce extension to 64 bytes, what if in the future there is a new hash algorithm or some proprietary hash function that requires size to be 128 bytes or 256 bytes or may be 100 GigaBytes, are we going to increase the size of the Nonce extension again?  How can we set an upper limit on Nonce which also serves the regular Nonce use case of just avoiding the replay attacks ?

I proposed 2 values: 96 bytes if we want to accomodate 512-bit hashes, or 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any hashing algorithm is designed to yield a relatively small result, so we're certainly not talking about GigaBytes here...

> In my opinion, ISO 14533 took advantage of the security vulnerability that existed in RFC6960 and tried using Nonce extension in a way it was not intended to be used as i.e. using an ASN.1 SEQUENCE where the standard requires use of OCTET STRING.

OCTET STRING means arbitrary sequence of bytes, which OCSP responder shouldn't interpret in any way - just echo them back in its response. It's completely irrelevant, what's encoded inside - after all, a random number could also start with 0x30 which corresponds to SEQUENCE.

> We should come up with a new extension for associating the OCSP response with the context where OCSP is being used for long term validation. That is the right thing to do.

And what will be the advantage of having yet another extension doing the same thing? Both use cases require nothing else from OCSP responder than to echo back exactly the same bytes it received in request. Do you propose to have 2 extensions, one of them being able to only echo 32 bytes and another being able to echo 96? or 160? or unlimited bytes? Isn't it much more straightforward to have only one "echoing" extension being able to echo as many bytes as needed for both use cases?

On the other hand, the disadvantages are significant - I mentioned some of them in my previous email. Also please keep in mind, that RFC 8954 (if applied by OCSP responder or by some firewall doing deep packet inspection) will immediately break digital signing - since it says:
 A server *MUST* reject any OCSP request that has a nonce in the Nonce
extension with a length of either 0 octets or more than 32 octets
with the malformedRequest OCSPResponseStatus

Last but not least, introducing another extension is more complex than you assume - it will require modification of (at least) RFC6960, RFC5019, ISO 14533-4. When will that solution be available and what to do until then?

With kind regards,

MD

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 23 Dec 2020 08:40:19 +0100

Hi,

I'd like to give my view on this.

I support not changing anything in RFC8954.

I recently started using the term "tweaking standards" for when you take
an existing field in a standard and use it for other purposes than the
one stated in the standard, just because it is technically possible and
not explicitly forbidden in the standard. This has been done many times
before, and many times it leads to interoperability issues, severe
spending of time, money and resources, and in severe cases even downtime.
Tweaking standards is a short term short-cut, ignoring long term costs.

ISO 14533 clearly tweaked RFC6960 section 4.4.1.

Many internet scale OCSP responders today do not include Nonce in the
response. Regardless if the client sends it. This is for caching
reasons, and is for both GET and POST requests.

Using nonce as MessageImprint is non-interoperable with RFC6960 and with
the real world.

I'd like to say it again: ISO 14533 is non-interoperable with how OCSP
is deployed on the internet today.

It is a disaster waiting to happen. The reason it hasn't happened yet is
likely due to ISO 14533 not being widely used. Let's fix it before it
falls apart.
The solution is not to force RFC6960 compliant OCSP responders into
submission to ISO 14533, but to fix ISO 14533.
ISO 14533 should recognize that the suggested solution is non-compliant,
causing interoperability issues, and go back and create an extension.
Yes, it's a little more work, and may result in a new RFC, or a
replacement of RFC6960 (but the extension can be private to ISO 14533 to
start with), but it's the right thing to do imho.

There is already an extension, a bit similar to this, specified in the
German Common PKI. https://de.wikipedia.org/wiki/Common_PKI
It's called CertHash and can be copied. The specification isn't
available any longer, but I have an off-line copy that I share here:
https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54

It's a SingleResponse extension, section 3.1.2:

id-commonpki-at-certHash OBJECT IDENTIFIER ::== {1 3 36 8 3 13}

CertHash ::= SEQUENCE {
  hashAlgorithm AlgorithmIdentifier, // The identifier of the algorithm
                                     // that has been used the for hash
                                     //value below.

  certificateHash OCTET STRING // A hash over the DER-encoding of the
                               // entire PKC or AC (i.e. NOT a hash
                               // over tbsCertificate).
}

There are OCSP responders out there supporting the old CertHash extension.

Not saying to use it "as is", it has another purpose, but very very
similar. Just put a new OID and rename it to MessageImprint...

Best regards,
Tomas

On 2020-12-21 17:36, Marian Ďurkovič wrote:
>> From OCSP point of view the MessageImprint is not a random value but
> it is a deterministic value generated for a given input by a collision
> random, some of them being unknown even to document signer (private
> key). In any case, an attacker is not able to guess this value so it
> serves against reply attack very well.
> 
> underlying hash algorithm.  Since RFC3161 does not provide a fixed list
> of Hash functions, let's say we change the size to Nonce extension to 64
> proprietary hash function that requires size to be 128 bytes or 256
> bytes or may be 100 GigaBytes, are we going to increase the size of the
> Nonce extension again?  How can we set an upper limit on Nonce which
> also serves the regular Nonce use case of just avoiding the replay attacks ?
> 
> I proposed 2 values: 96 bytes if we want to accomodate 512-bit hashes,
> or 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any
> hashing algorithm is designed to yield a relatively small result, so
> we're certainly not talking about GigaBytes here...
> 
> that existed in RFC6960 and tried using Nonce extension in a way it was
> not intended to be used as i.e. using an ASN.1 SEQUENCE where the
> standard requires use of OCTET STRING.
> 
> shouldn't interpret in any way - just echo them back in its response.
> It's completely irrelevant, what's encoded inside - after all, a random
> number could also start with 0x30 which corresponds to SEQUENCE.
> 
>> We should come up with a new extension for associating the OCSP
> response with the context where OCSP is being used for long term
> validation. That is the right thing to do.
> 
> same thing? Both use cases require nothing else from OCSP responder than
> to echo back exactly the same bytes it received in request. Do you
> propose to have 2 extensions, one of them being able to only echo 32
> bytes and another being able to echo 96? or 160? or unlimited bytes?
> Isn't it much more straightforward to have only one "echoing" extension
> being able to echo as many bytes as needed for both use cases?
> 
> On the other hand, the disadvantages are significant - I mentioned some
> of them in my previous email. Also please keep in mind, that RFC 8954
> (if applied by OCSP responder or by some firewall doing deep packet
> inspection) will immediately break digital signing - since it says:
> 
> Last but not least, introducing another extension is more complex than
> you assume - it will require modification of (at least) RFC6960,
> RFC5019, ISO 14533-4. When will that solution be available and what to
> do until then?
> 
> With kind regards,
> MD
> 
> 
> 
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 23 Dec 2020 08:56:04 +0100

CertHash is also mentioned in the eIDAS rgulation acording to this.
https://ec.europa.eu/cefdigital/tracker/secure/attachment/17296/17296_OCSP+and+Article+24-4+of+eIDAS+EU+regulation+910-2014.pdf

And the below should be specific to ISO 14533-4 (PoEAttributes), it's
not generic for CAdES.

> I'd like to say it again: ISO 14533-4 is non-interoperable with how
> OCSP is deployed on the internet today.

Of course, the MessageImprint ASN.1 is identical to CertHash, just
another OID. It's nothing special to add an extension for this.

Regards,
Tomas

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Dec 2020 10:41:25 -0500

Dear  IAB:

The IETF does not have a liaison relationship with the ISO TC that produced ISO 14533-4:2019.  It would be a good think to tell that group that we disagree with the approach that was taken.  What does the IAB suggest?

Russ

> On Dec 23, 2020, at 2:40 AM, Tomas Gustavsson <[email-masked]> wrote:
> 
> 
> Hi,
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Dec 2020 16:09:19 +0000

Hi Russ,

On 23/12/2020 15:41, Russ Housley wrote:
> Dear  IAB:
> 
> The IETF does not have a liaison relationship with the ISO TC that
> produced ISO 14533-4:2019.  It would be a good think to tell that
> group that we disagree with the approach that was taken.  What does
> the IAB suggest?

I've not followed this discussion, nor am I at all familiar
with that ISO spec, so I'd have to get up to speed before I'd
have an informed opinion.

Does anyone know someone involved with that ISO group/spec?
If so, I'd say trying to see if it can be sorted out at that
level would be good (if it's not happened already).

If there's no good contact available then yeah I guess the
IAB might try find a way to send a message to ISO. First up
though might be for lamps to craft the message to be sent
(including enough background that IAB and ISO folks will get
the point). I'd be happy to bring such a message to the IAB
and ask that we figure out how to get it sent to the right
place/people.

Cheers,
S.

PS: The above is clearly just me speaking, and isn't the
consensus of the IAB:-)

>> I recently started using the term "tweaking standards" for when you
>> take an existing field in a standard and use it for other purposes
>> than the one stated in the standard, just because it is technically
>> possible and not explicitly forbidden in the standard. This has
>> been done many times before, and many times it leads to
>> interoperability issues, severe spending of time, money and
>> resources, and in severe cases even downtime. Tweaking standards is
>> a short term short-cut, ignoring long term costs.
>> 
>> Many internet scale OCSP responders today do not include Nonce in
>> the response. Regardless if the client sends it. This is for
>> caching reasons, and is for both GET and POST requests.
>> 
>> Using nonce as MessageImprint is non-interoperable with RFC6960 and
>> with the real world.
>> 
>> I'd like to say it again: ISO 14533 is non-interoperable with how
>> It is a disaster waiting to happen. The reason it hasn't happened
>> yet is likely due to ISO 14533 not being widely used. Let's fix it
>> before it falls apart. The solution is not to force RFC6960
>> compliant OCSP responders into submission to ISO 14533, but to fix
>> ISO 14533. ISO 14533 should recognize that the suggested solution
>> is non-compliant, causing interoperability issues, and go back and
>> create an extension. Yes, it's a little more work, and may result
>> in a new RFC, or a replacement of RFC6960 (but the extension can be
>> private to ISO 14533 to start with), but it's the right thing to do
>> imho.
>> 
>> There is already an extension, a bit similar to this, specified in
>> the German Common PKI. https://de.wikipedia.org/wiki/Common_PKI 
>> available any longer, but I have an off-line copy that I share
>> here: https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54
>> 
>> CertHash ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, // The
>> identifier of the algorithm // that has been used the for hash 
>> //value below.
>> 
>> certificateHash OCTET STRING // A hash over the DER-encoding of
>> the // entire PKC or AC (i.e. NOT a hash // over tbsCertificate). 
>> }
>> 
>> Not saying to use it "as is", it has another purpose, but very
>> very similar. Just put a new OID and rename it to
>> MessageImprint...
>> 
>> Best regards, Tomas
>> 
>> 
>>> it is a deterministic value generated for a given input by a
>>> collision resistant one way hash function.
>>> 
>>> This input, however, consists of multiple parts: some of them
>>> being random, some of them being unknown even to document signer
>>> (private key). In any case, an attacker is not able to guess this
>>> value so it serves against reply attack very well.
>>> 
>>> that the length of MessageImprint is not fixed but varies based
>>> on the underlying hash algorithm.  Since RFC3161 does not provide
>>> a fixed list of Hash functions, let's say we change the size to
>>> Nonce extension to 64 bytes, what if in the future there is a new
>>> hash algorithm or some proprietary hash function that requires
>>> size to be 128 bytes or 256 bytes or may be 100 GigaBytes, are we
>>> going to increase the size of the Nonce extension again?  How can
>>> we set an upper limit on Nonce which also serves the regular
>>> Nonce use case of just avoiding the replay attacks ?
>>> 
>>> I proposed 2 values: 96 bytes if we want to accomodate 512-bit
>>> hashes, or 160 bytes, if we want to accomodate (future) 1024-bit
>>> hashes. Any hashing algorithm is designed to yield a relatively
>>> small result, so we're certainly not talking about GigaBytes
>>> here...
>>> 
>>> that existed in RFC6960 and tried using Nonce extension in a way
>>> it was not intended to be used as i.e. using an ASN.1 SEQUENCE
>>> where the standard requires use of OCTET STRING.
>>> 
>>> OCTET STRING means arbitrary sequence of bytes, which OCSP
>>> responder shouldn't interpret in any way - just echo them back in
>>> its response. It's completely irrelevant, what's encoded inside -
>>> after all, a random number could also start with 0x30 which
>>> corresponds to SEQUENCE.
>>> 
>>> And what will be the advantage of having yet another extension
>>> doing the same thing? Both use cases require nothing else from
>>> OCSP responder than to echo back exactly the same bytes it
>>> received in request. Do you propose to have 2 extensions, one of
>>> them being able to only echo 32 bytes and another being able to
>>> echo 96? or 160? or unlimited bytes? Isn't it much more
>>> straightforward to have only one "echoing" extension being able
>>> to echo as many bytes as needed for both use cases?
>>> 
>>> On the other hand, the disadvantages are significant - I
>>> mentioned some of them in my previous email. Also please keep in
>>> mind, that RFC 8954 (if applied by OCSP responder or by some
>>> firewall doing deep packet inspection) will immediately break
>>> digital signing - since it says:
>>> 
>>> A server *MUST* reject any OCSP request that has a nonce in the
>>> Nonce extension with a length of either 0 octets or more than 32
>>> octets with the malformedRequest OCSPResponseStatus
>>> 
>>> Last but not least, introducing another extension is more complex
>>> than you assume - it will require modification of (at least)
>>> RFC6960, RFC5019, ISO 14533-4. When will that solution be
>>> available and what to do until then?
>>> 
>>> With kind regards, MD
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________ Spasm mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>>> 
>> 
>> _______________________________________________ Spasm mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________ Spasm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Dec 2020 11:20:47 -0500

Marian Ďurkovič <[email-masked]> brought it to the attention of the LAMPS WG.  That was a message out of the blue from my perspective.

Russ

> On Dec 23, 2020, at 11:09 AM, Stephen Farrell <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Hi Russ,
> 
>>> the German Common PKI. https://de.wikipedia.org/wiki/Common_PKI It's called CertHash and can be copied. The specification isn't available any longer, but I have an off-line copy that I share
>>> identifier of the algorithm // that has been used the for hash //value below.
>>> the // entire PKC or AC (i.e. NOT a hash // over tbsCertificate). }
>>>> response with the context where OCSP is being used for long term validation. That is the right thing to do.
>>> _______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>> _______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm
> <OpenPGP_0x5AB2FAF17B172BEA.asc>
> 
>