Re: [lamps] [EXTERNAL] CMP vs RFC5280

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

Max

 

Thank you for pointing at the differences of ITU-T X.509 2019 and RFC 5280.

I just submitted a new version of the draft completely removing the
reference to ITU-T X.509.

 

Hendrik

 

Von: Spasm <[e-mail]> Im Auftrag von Mike Ounsworth
Gesendet: Mittwoch, 20. März 2024 10:18
An: madwolf <[e-mail]>; [e-mail]
Betreff: Re: [lamps] [EXTERNAL] CMP vs RFC5280

 

Good point Max.

 

I think the intent here is to fully reference the RFC 5280 definition of
X.509, and fully separate from the ITU definition of X.509.

 

- Mike Ounsworth

  _____  

From: Spasm <[e-mail] <mailto:[e-mail]> > on
behalf of madwolf <[e-mail] <mailto:[e-mail]> >
Sent: Wednesday, March 20, 2024 3:23:10 PM
To: [e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] CMP vs RFC5280 

 

Hi Hendrik, All, I support the change. I too think it should be safe. I just
wanted to add something for the initial question about updating the
reference to the 2019 version of ISO (or subsequent errata) and I think it
might not be a good 

Hi Hendrik, All,

I support the change. I too think it should be safe. 

I just wanted to add something for the initial question about updating the
reference to the 2019 version of ISO (or subsequent errata) and I think it
might not be a good idea since the 2019 version introduces support for
altSignature* and keys for hybrids that we do not have in 5280.

Kind Regards,
Massimiliano

On 3/19/2024 6:40 AM, Brockhaus, Hendrik wrote:

Thank you for this finding. I opened
https://github.com/lamps-wg/cmp-updates/issues/55

 

Doing some research on the topic, I found following:

 

RFC 2510 / RFC 4210 define “certificate” as defined in ITU-T X.509 in the
abstract / in the introduction. 

Of course, the term “certificate” is used on many many places.

 

RFC 2510 and RFC 4210 use the types Certificate as defined in RFC 2459.

RFC 4210 introduces the ASN.1 type CMPCertificate.

      CMPCertificate ::= CHOICE {

         x509v3PKCert        Certificate

      }

   -- This syntax, while bits-on-the-wire compatible with the

   -- standard X.509 definition of "Certificate", allows the

   -- possibility of future certificate types […]

 

With the 2002 ASN.1 module updates the type Certificate is imported from the
2002 ASN.1 module of RFC 5280.

As the ASN.1 module in rfc4210bis in based upon that 2002 ASN.1 module, it
clearly imports from RFC 5280. Therefore, I think it is safe to change the
reference from ITU-T X.509 to RFC 5280.

 

What do others think?

 

Hendrik

 

Von: Mike Ounsworth  <mailto:[e-mail]>
<[e-mail]> 
Gesendet: Dienstag, 19. März 2024 06:07
An: Russ Housley  <mailto:[e-mail]> <[e-mail]>;
Michael Richardson  <mailto:[e-mail]> <[e-mail]>;
Brockhaus, Hendrik (T CST SEA-DE)  <mailto:[e-mail]>
<[e-mail]>
Cc: [e-mail] <mailto:[e-mail]> 
Betreff: Re: [lamps] [EXTERNAL] CMP vs RFC5280

 

 <mailto:[e-mail]> @Brockhaus, Hendrik we should create
a GitHub issue for this.

 

- Mike Ounsworth

  _____  

From: Russ Housley <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, March 19, 2024 2:59:20 PM
To: Mike Ounsworth <[e-mail]
<mailto:[e-mail]> >; Michael Richardson
<[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] CMP vs RFC5280 

 

Mike: > Hmm. 4210 pre-dates 5280. I suppose there are two questions here: >
> 1) can someone who was around please illuminate on why 2510/4210
references an ISO doc and not an IETF doc (2459/3280/5280)? I do not recall
why RFC 2510 

Mike:
 
> Hmm. 4210 pre-dates 5280. I suppose there are two questions here:
> 
> 1) can someone who was around please illuminate on why 2510/4210
references an ISO doc and not an IETF doc (2459/3280/5280)?
 
I do not recall why RFC 2510 did not reference RFC 2459.  However, the
development of the two documents was going on at the same time.  My guess is
that we did not know which would reach the RFC Editor first.
 
> 2) Is it a trivial change to swap out the X.509 reference? Or will that
turn into a cascade of difference-hunting and backwards compatibility? Is
that worth doing?
 
Reference to RFC 5280 seems like the right thing to do today.
 
Russ
 

Any email and files/attachments transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed. If this
message has been sent to you in error, you must not copy, distribute or
disclose of the information it contains. Please notify Entrust immediately
and delete the message from your system. 





_______________________________________________
Spasm mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/spasm