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.
The two drafts shall move along together. Until RFC 9480 was release there was nothing to do from the author's side. Therefor the draft expired. But I am preparing an update with some minor editorial changes from RFC 9480.

I see you points regarding the ASN.1 module names and OIDs. I need to think about it and come back to your suggestions. Thank you.
As I am not an ASN.1 module expert, I appreciate any proposals.

Hendrik

Von: Michael StJohns <[e-mail]>
Gesendet: Donnerstag, 14. Dezember 2023 20:39
An: Brockhaus, Hendrik (T CST SEA-DE) <[e-mail]>; Russ Housley <[e-mail]>
Cc: LAMPS <[e-mail]>
Betreff: Re: AW: [lamps] draft-ietf-lamps-rfc4210bis was: Re: WG Last Call: draft-ietf-lamps-x509-policy-graph-01

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.

--> 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).

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.

--> 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?

--> 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.

Later, Mike

Hendrik

Von: Spasm <[e-mail]><mailto:[e-mail]> Im Auftrag von Michael StJohns
Gesendet: Samstag, 9. Dezember 2023 22:53
An: Russ Housley <[e-mail]><mailto:[e-mail]>
Cc: LAMPS <[e-mail]><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