Dear Benjamin: Thanks for your answer. See ours below.
> El 19 nov 2020, a las 12:30, Benjamin Kaduk <[email protected]> escribió: > > 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. [Authors] Correct. > 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.) [Authors] Regarding this, it is worth noting that RFC 7296 (IKEv2) defines the following (3.5. Identification Payloads) ID_DER_ASN1_DN 9 The binary Distinguished Encoding Rules (DER) encoding of an ASN.1 X.500 Distinguished Name [PKIX]. These identities in the ID payload in IKEv2 are used to search in the PAD. Thus, do you think it would be reasonable to express it in the same way as IKEv2 RFC? On the other hand, however, it refers to [PKIX], which is RFC 5280. Is this acceptable? Following IKEv2 definition for ID_DER_ASN1_DN , it would be something like this: case dnx509 { leaf dnx509 { type binary; description "The binary Distinguished Encoding Rules (DER) encoding of an ASN.1 X.500 Distinguished Name."; reference "RFC 5280."; } } Best Regards. > > -Ben > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] -------------------------------------------------------
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
