On Tue, Nov 17, 2020 at 06:37:09PM -0800, Benjamin Kaduk wrote: > > On Mon, Nov 16, 2020 at 06:44:35PM +0100, Rafa Marin-Lopez wrote: > > > El 5 nov 2020, a las 5:53, Benjamin Kaduk via Datatracker > > > <[email protected]> escribió: > > > > > > The ASN.1 GeneralName type is an abstract type; in order to represent it > > > in a string we must have some discussion of how it is encoded. (A > > > similar concern might apply to the other ASN.1 types used, such as > > > DistinguishedName, though the latter does have a fairly well-established > > > string presentation form, so the concern is of lesser magnitude there. > > > That said, RFC 5280 is not a suitable reference for the > > > DistinguishedName string presentation form.) > > > > [Authors] We definitely need your guidance here. We believe this is also > > related to the e-mail exchange with Tom Petch about the DistinguisedName. > > In the DistinguisedName, it seems we have to wait to know the proper > > reference since RFC 2247 is not valid. > > Okay, I will see if I can pester a couple experts in the "hallway" this > week to see if X.520 is really the best/only reference for > DistinguishedName.
Okay, I made a bit of progress on this one -- if we are set on using the string representation of the distinguished name, RFC 4514 is better than 2247. But I'm not entirely sure I understand why the string representation is the desired one, here. If we just want a way to list the identity of an entity that will use an X.509 certificate to validate that identity, then just taking the raw (binary) bytes from the certificate itself seems like it would be simpler and more reliable. (In theory this will always be DER encoded ASN.1, but in practice some non-DER BER variants will be accepted by some implementations, so using the raw bytes and not trying to re-encode is most reliable.) -Ben _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
