Figure out what to do about RFC 2560/6960 ResponderID byKey definition

[CBonnell]

Both RFC 2560 and 6960 have this little gem in the ASN.1:

ResponderID ::= CHOICE {
   byName   [1] Name,
   byKey    [2] KeyHash }

KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
                         --(excluding the tag and length fields)

Unfortunately, I don't see another way to "override" this use of SHA-1 such that it could be understood by OCSP clients. I'm inclined to think we're stuck with this use of SHA-1, but I hope I'm wrong.

Thoughts?

[CBonnell]

It just dawned on me that we might be able to define the byKey value as the value of the responder certificate's (either direct or delegated signer) SKID extension. This would require that all OCSP delegated responder certs contain the SKID, but the inclusion of this extension is quite common and SKID generation method 1 of 5280 is commonly used, so this redefinition should have little real world impact.

[tadahik]

I confirmed use of SHA-1 in byKey. I am thinking that, our document is updating RFC5019, to fix conflict along with RFC 6960. In the other hand, to change use of SHA-1 in byKey, we need to update RFC6960.

For me, it seems it is more simple to publish this 5019bis as it is, and make new I-D(6960bis) to update 6960. (As far as I understand, both 6960 and (overriding)6960bis would not have conflict with 5019bis. )

[CBonnell]

Can we make our draft update both 5019 and 6960? There is precedent for that such as RFC 8996: https://datatracker.ietf.org/doc/html/rfc8996.

[tadahik]

I think we can update both 5019 and 6960 in one draft, but I think it is better to divide. I am not sure what Sean or Russ would say but in my understanding,

• In 8996, there was strong consensus. but we do not have that strong consensus yet.
• 8996 updates many RFCs, but that is Best Current Practice paper and show changes in use of RFCs. we want to change standard track document itself. I think it make some difference.
• We still able to updates several standard track document together, but... -- change of byKey (in 6960) might need some backward compatibility discussion, which tend to be long (unlike current draft) and can be very long. -- updating 6960 might lead many work, and possibly need to work for additional unexpected indications. -- some people may say we need to update more RFCs related with sha-1, which would also consume additional work again and again...

I believe, good way is marge 5019 to 6960 (now), then update 6960 with several RFCs, then marge those RFCs and make 6960bis. (to divide into small steps, and we can focus into each step's discussion).

[CBonnell]

Thanks for explaining the concern, @tadahik. You've convinced me that we should spin up another draft to address the byKey algorithm.

@clintwilson @seanturner do you agree with this approach?

[seanturner]

To confirm you can definitely update more than one RFC with another, but I can already see the epic bikeshed about what to call the I-D ;) Splitting makes sense to me.

[tadahik]

I was making presentation slide for IETF117, and thinking about what would be goal for this draft.. https://github.com/tadahik/RFC5019bis/blob/117Presentation/117Presentation/IETF117Presentation.pptx

I believe, we can chose from 3 goal as following(I wrote in slide also), and I thought 1st option would work good. However, I am not sure if my understanding is correct, and we might be able to ask WG which one is good way to do.

• Allow use of SHA-256 for “High-Volume Environments” -- Current Approach -- OCSP responder/client will not use sha-256 after 6960-bis, but need sha-1 by then

• Do not require sha-1 for OCSP responder/client -- need to update both 5019 and 6960 -- change definition of byKey of responderID from sha-1 to sha-256 -- may cause interoperability issue for non-5019 client and responder.

• Do not require sha-1 for OCSP responder/client for “High-Volume Environments” -- How to calculate responderID? is problem -- calculate byKey of of responderID to sha256?  >> conflict with RFC6960 -- Do not calculate with sha-1, but refer SKID  >> interoperable with RFC 6960 -- require that all OCSP delegated responder certs contain the SKID

Any suggestion?

[tadahik]

3rd option may not need to update 6960. it seems similar to 6277 and make it something like "Online Certificate Status Protocol Algorithm Agility for High-Volume Environment"... but still not quite sure about how people would think use of SKID..

[tadahik]

6960 is general profile, and 5019 is high volume env profile, so I believe it is fine that 5019-bis depend on 6960, but changing 6960 for 5019 seems more interoperability problem.

[tadahik]

@CBonnell Hi I updated slide,

I was thinking that there would be two important potential question. could you confirm that we are in same view, or if i am lacking something. (or I am writing to much, which I had better not to talk at WG )

[Q]Why you do not marge and make 6960-bis? [A]We believe it is great to make 6960-bis, however,

• 5019-bis is about profile on high-voulume environments, but 6960-bis is about general protocol, they are quite different. in addition, 6960-bis would take much longer to process.
• 6960-bis would have many other discussion apart from SHA-1 issue

[Q]Why you do not marge change on responderID to the draft? [A]We can, but with following reason, we prefer to separate

• Migrations of a profile and a protocol tend to be different
• Scope of migration / backward compatibility would be much broader for 6960-bis
• Some solution might cause some problem to state ASN.1 module

@clintwilson Hi client, In current approach of 5019-bis, we would able to migrate SHA-1 certID to SHA-2 CertID relatively faster, but would need another internet-draft to move from SHA-1 responderID to SHA-2 responderID. is it OK?

I believe we (authors) do not have consensus of moving to SHA-2 responderID. Do you think you would endorsee migration of SHA-1 responderID to SHA-2 ResponderID? so far i agree that migration also, and it might be good chance to discuss on the WG.

( I believe Corey's idea of using SKID is good, but not sure about potential issues on implementation and ASN.1 module.)

[clintwilson]

Hey @tadahik, I think this approach seems good and indeed my focus has been on the restriction 5019 places on certID, disallowing use of anything but SHA-1. Removing that restriction is (or should be), I think, a relatively straightforward case to make to the WG and one upon which I think broad consensus can be built.

Beyond that there are a whole slew of other updates (minor and major) these documents can benefit from, however those benefits are also balanced against ecosystem reliance, use, and support of OCSP. Currently OCSP is heavily relied upon, but we're moving fairly quickly towards a time where it's used, but not relied upon. I expect some time will pass in that state, but we may then end up with OCSP being supported and not used. Finally, support could be dropped, at which point many of the updates we're talking about may not ultimately be worthwhile.

Which is to say, once we start looking at larger updates to these RFCs, I think we maybe need to look even bigger -- much bigger. How can OCSP be privacy-preserving by default? How can it scale to real-world use-cases evolved over the last decade? What has contributed to OCSP-stapling's adoption remaining insignificant on internet-scale? What has contributed to OCSP becoming optional in the CA/BF? Is it worth the effort to address these issues and "fix" OCSP, or would time be better spent standardizing something else (CRL coalescing technologies as one possibility)?

[tadahik]

@clintwilson Thanks Clint, You gave us great points, and also...

Currently OCSP is heavily relied upon, but we're moving fairly quickly towards a time where it's used, but not relied upon. I expect some time will pass in that state, but we may then end up with OCSP being supported and not used

I just thought, it is very good point for focusing CertID, but not for responderID. CertID may be able to be useful for other revocation mechanism, because you can identify the certificate. In the other hand, responderID would be much less useful in that perspective.

Now I thing I would be much more comfortable to defend statement of focus on just SHA-1 on CertID.

[CBonnell]

@tadahik sorry for the delayed response. My work laptop died Friday morning and the replacement just arrived this morning.

I agree with your proposal to defend our decision to not write a 6960-bis at this time, nor attempt to solve the ResponderID problem as part of our draft. Currently, our draft has a small, well defined scope that tackles an important part of migration from SHA-1.

As for the presentation, I think it's a great start and we can work on finalizing it this weekend in San Francisco. I would suggest adding the third option to slide 4, which is to sign and distribute one OCSP response per hash algorithm. On the list, we rejected this approach, but it may be good to mention it briefly and explain why we are not pursuing it further.

[tadahik]

Thanks @CBonnell

work on finalizing it this weekend in San Francisco.... third option to slide 4,...

Good Ideas, I will see you in San Francisco.

[tadahik]

We explained difference on profile(RFC5019) and protocol(6960), and we are just changing profile. https://datatracker.ietf.org/doc/draft-bonnell-rfc5019bis/ It seems we had support for that idea. closed issue