Re: [lamps] draft-ietf-lamps-rfc4210bis was: Re: WG Last Call: draft-ietf-lamps-x509-policy-graph-01

["Brockhaus, Hendrik" <[e-mail]>]

Mike

Thank you for your comments and proposals.
I responded inline below.

> Von: Michael StJohns <[e-mail]> 
> Gesendet: Donnerstag, 14. Dezember 2023 20:39
>
>> On 12/11/2023 2:21 AM, Brockhaus, Hendrik wrote:
>> Mike
>> 
>> Thank you for pointing this out. I was also thinking about how to best express this.
>> My understanding is that 4210bis obsoletes 4210 and 9480 and updates 5912. In parallel 6712bis obsoletes 6712 and 9480.
>> I am preparing updated versions of both -bis drafts on https://github.com/lamps-wg/cmp-updates/ reflecting the released documents RFC9480 - RFC9483.
>> I am currently following the discussion on cms-kemri regarding the KDF input as is may also affect the specification of KEM-based message protection in 4210bis Section 5.1.3.4.
>> 
>> As always, any feedback or proposal are welcome.
> Hi - 
> --> The 6712bis draft is expired since February.  If these are a pair, they'll need to move along together.  If they both move then I think your approach works.

[HB] I will update rfc4210bis together with rfc6712bis soon.
Back when I started working on the CMP Updates draft, I took RFC 6402 as good practice. RFC 6402 updates RFC 5272, RFC 5273, and RFC 5274. In the meantime, work on rfc5272bis, rfc5273bis, and rfc5274bis was started. All three will obsolete RFC 6402. This looks like the same approach I took for rfc4210bis and rfc6712bis.

This is the current picture of dependencies (update and obsoletion):
RFC 2510:
   Was obsoleted by RFC 4210.
RFC 4210:
   Was updated by RFC 9480 and RFC 9481, and will be obsoleted by rfc4210bis.
RFC 5912:
   Was updated by RFC 9480 and will be updates by rfc4210bis.
RFC 6712:
   Was updated by RFC 9480, and will be obsoleted by rfc6712bis.
RFC 9480:
   Will be obsoleted by rfc4210bis and rfc6712bis.

> --> The OID/NAME for the updated 5912 module bothers me.  RFC4210 has PKIXCMP - with a module of id-mod-cmp2000 (16) under 1.3.6.1.4.1.5.5.7.0.   RFC5912 has  PKIXCMP-2009 with id-mod-cmp2000-02 (16).   RFC9480 has PKIXCMP with id-mod-cmp2021-88 (99) and PKIXCMP-2021 with id-mod-cmp2021-02(100).

[HB] I guess you mean 'id-mod-cmp2000-02 (50)'

> 4210bis  has PKIXCMP-2023 and id-mod-cmp2023-02(TBD2).  Not sure what the -02 gives you here - or is that meant to indicate 2002 standard?  If so - maybe PKIXCMP-2023-02 as well.
> This seems a bit scattershot and makes it a bit difficult to figure out which ASN1 module supersedes another one.  Would versioning the OID make more sense?  (e.g. same module number plus two components for major/minor versions).  So 1.3.6.1.4.1.5.5.7.0.16.2023.1 for PKIXCMP-2023? (Or PKIXCMP-2023-02?).
> --> Is there a standard practice in the PKIX world for module and module tag names and OIDs for replacement modules?  Does IANA have such a thing?
> --> RFC9480 has the notation that PKIX still considers -88 modules to be the gold standard.  Is this still the case?  From A.1 of RFC9480:
> Although a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the normative module, as per the policy of the PKIX Working Group.

[HB] The overall situation regarding the ASN-1 module the situation is as follows.
For ASN.1 1988 Syntax modules the name is always PKIXCMP and the versioning was done by the ID following the example of RFC 2510 and RFC 4210. For ASN.1 2002 Syntax module the year of developing it was added to the name and the -02 was added to the versioning in the ID following the guidance of RFC 5912. But I see that this may not be sufficiently clear.
As I am not that experienced with ASN.1 modules, I am happy for any proposals enhancing clarity here. If there is any guidance on naming module versions, I would need a pointer to that.

RFC 2510:
   1988 Syntax, PKIXCMP, 1.3.6.1.5.5.7.0.9 (id-mod-cmp)
   Obsoleted by RFC 4210 PKIXCMP1.3.6.1.5.5.7.0.16 (id-mod-cmp2000)
RFC 4210:
   1988 Syntax, PKIXCMP, 1.3.6.1.5.5.7.0.16 (id-mod-cmp2000)
   Replaced by RFC 9480 PKIXCMP 1.3.6.1.5.5.7.0.99 (id-mod-cmp2021-88)
RFC 5912:
   2002 Syntax, PKIXCMP-2009, 1.3.6.1.5.5.7.0.50 (id-mod-cmp2000-02)
   Replaced by RFC 9480 PKIXCMP-2021 1.3.6.1.5.5.7.0.100 (id-mod-cmp2021-02)
RFC 9480:
   1988 Syntax, PKIXCMP, 1.3.6.1.5.5.7.0.99 (id-mod-cmp2021-88)
   2002 Syntax, PKIXCMP-2021, 1.3.6.1.5.5.7.0.100 (id-mod-cmp2021-02)
   Both modules will be obsoleted by rfc4210bis PKIXCMP-2023 1.3.6.1.5.5.7.0.TBD2 (id-mod-cmp2023-02)
rfc4210bis:
   2002 Syntax, PKIXCMP-2023, 1.3.6.1.5.5.7.0.TBD2 (id-mod-cmp2023-02)

As RFC 9480 updates and not obsoletes RFC 4210, this was also my understanding. But I thought that with rfc4210bis, as it obsoletes RFC 4210 and RFC 9480, we can switch to the ASN.2 2002 version module as the normative one and obsolete the ASN.1 1988 version module. Is this strategy appropriate?

> --> Next - for the changes to the body of the module, are there any upstream modules where such a change could be problematic or limiting?  E.g. importing an enum that's been extended?  (Do we have a tool for scanning for imports and doing the cross verification?

[HB] I am not aware of any such dependencies. A appreciate any help if one has tooling at had to check for such dependencies.
The only issue I came across when drafting RFC 9480 was the definition of pkcs-9-at-localKeyId. For the ASN.1 1988 module I had do define the type directly, for the ASN.1 2002 module I could import it from the PKCS #9 module, see https://mailarchive.ietf.org/arch/msg/spasm/1dPI3qrpOuRxwWx2Z8tzu9PQTtA/

> --> Lastly, it would probably make sense to include within the body of the module (in ASN1 comment blocks) the OID of the module this one is replacing and  the specific changes or updates that were made between the two.  e.g. for the most part the extracted module ought to be stand-alone.

[HB] The ASN.1 modules in RFC 9480 contain comments on the changes made by this RFC, but they are not as block in the beginning. I will add a more complete change history.

Hendrik

> Later, Mike
> 
>> Hendrik
>>> 
>>> Von: Spasm mailto:[e-mail] Im Auftrag von Michael StJohns
>>> Gesendet: Samstag, 9. Dezember 2023 22:53
>>> An: Russ Housley mailto:[e-mail]
>>> Cc: LAMPS mailto:[e-mail]
>>> Betreff: [lamps] draft-ietf-lamps-rfc4210bis was: Re: WG Last Call: draft-ietf-lamps-x509-policy-graph-01
>>> 
>>> Thanks for the changes in the write up.  Comment below.
>>> 
>>> 
>>> On 12/9/2023 4:19 PM, Russ Housley wrote:
>>>> Mike:
>>>> 
>>>>> On 12/8/2023 2:56 PM, Russ Housley wrote:
>>>>> I didn't actually notice that one at the time - now RFC 9480. But what a mess.   I see that there is a RFC4210bis  document in progress (https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc4210bis/) and not one for 4211 - is that the one you meant?  I also see that the 4210bis document is missing an Obsoletes RFC9480 tag, except it can't have one because RFC9480 updates multiple documents... I'm not seeing this as a shining example of what to do....  the only saving grace is that the referenced document here  is only cutting and pasting  a single upstream document.
>>>>> 
>>>> Yes, I meant RFC 4210.
>>>> 
>>>> RFC 4210 is updated by RFC 6712, RFC 9480, and RFC9481.  rfc4210bis should obsolete RFC 4210 and RFC 9480.
>>> 
>>> Except that RFC9480 doesn't just update RFC 4210. It also updates RFC 5912 and RFC 6712. If you obsolete 9480, what does that mean for the changes marked within that document that apply to 5912 and 6712? Generally "Obsolete" in RFC speak means "completely replaced", but the 4210bis document doesn't completely replace RFC9480. 
>>> Can a document be "Updated By" a second document that's marked as Obsolete? 
>>> As I said - this looks like a mess. 
>>> Mike
>>> 
>>> 
>>>