[Ediint] Re: AS2 GET (aka well-known/as2)

[Erik Wramner <[e-mail]>]

I would say most organizations use the same certificate for signing and encryption, but not all. Many have distinct signing certificates and encryption certificates. There are usage flags on the certificate itself as to what it can be used for, but it is more convenient to be able to read that from the XML. Plus, many products can have dual-use certificates that are only used in one role in practice. So yes, separate certificates can be used and are used in the wild.

-Erik

-----Original Message-----
From: Asger Smidt <[e-mail]> 
Sent: Monday, 19 October 2026 15:32
To: Erik Wramner <[e-mail]>; [e-mail]
Subject: RE: [Ediint] AS2 GET (aka well-known/as2)

Hi Erik,

I agree with you about the sync/async thing. That should be handled exclusively by the protocol. I am aware of systems that allow/require this to be configured directly on a profile however. Ours doesn't, but I have seen ones that do. So with that in mind, it is probably fine to include it, even if it seems pointless. It shouldn't hurt anything, anyway.

About the certificates, I wasn't thinking straight. The communication goes both ways of course. I still don't really see the need for a usage field though, since in my mind, each party's public certificate is used for encryption in one direction and validation in the other. Am I wrong about this? Do some entities use separate certificates for those two things? I have never encountered that before.

I confess that my knowledge about the inner workings of certificates is incomplete. I thought the thumbprint was baked into the certificate somehow, because I have seen the data point in various UIs and in internal data structures when debugging. I did not know it was calculated on-the-fly by whatever was reading the certificate.

As for the namespace, I'm fine with leaving it out. As you say, many people do not really know how to deal with them, and in this particular case I also do not see a great need for it. I just wanted to raise the issue.

/Asger

-----Original Message-----
From: Erik Wramner <[e-mail]> 
Sent: Monday, 19 October 2026 15.16
To: Asger Smidt <[e-mail]>; [e-mail]
Subject: RE: [Ediint] AS2 GET (aka well-known/as2)

Hi!

Good comments. As I wrote, this is mostly from Sinowintop, so in some cases I don't know why they did it in a certain way. Personally, I wouldn't bother about sync/async MDN for example, as I would always prefer sync and the final choice is communicated with HTTP headers anyway, but I'm fine with having it as they wanted it.

Certificate question: no, this must support signature and encryption and dual use certificates. To configure your own side, you need to get the partner's signing certificate to verify that, as well as their encryption certificate when sending to them. At least my intention is to have all the data available, so a user would just enter the base URL and press "Configure", then perhaps "Accept" when the fields have been filled in. If you don't have the signing certificate, you would have to get that somehow using another channel... which would make the auto-discovery much less useful. As a side note, Debra noted that this could be used as an alternative to CEM (though much less secure) for keeping certificates up to date.

Double certificate structure: we can rename one occurrence, for example to LocalPartyCertificates or CertificateReferences. Ease of use is always good.

Thumbprint: that opens up "sha-1 or sha-256 thumbprint" (this is for human reading not security and sha-1 is actually much easier to read) and heated discussions about that... plus it will have to be calculated. I don't have a strong view on this, though.

Namespace: we could add one, but many people don't really understand namespaces. It is easier without and no real risk for confusion. That said, the main reason for not having one is that Sinowintop didn't use it. I can add a namespace when I create the XSD if you (the group) like.

-Erik

-----Original Message-----
From: Asger Smidt <[e-mail]> 
Sent: Monday, 19 October 2026 14:56
To: Erik Wramner <[e-mail]>; [e-mail]
Subject: RE: [Ediint] AS2 GET (aka well-known/as2)

Hi Erik,

Overall I'd say it looks very good, but I do have a couple of questions/comments.

What is the purpose of the <Usage> field? Given that this is data presented to someone who wants to engage in AS2 communication with the LocalParty in question, I assume it refers to what THEY (the someone, not the LocalParty) should use the certificate for. Will that not always be encryption and only that?

While not against it on principle, I am slightly concerned that the structure Certificates/Certificate exists twice in the structure. I know from experience that some people tend to be somewhat "lazy" when writing XPath statements, and in this case the XPath //Certificates/Certificate is going to return data from two different places in the structure. It is of course not advised to use wildcards in XPath queries, but that unfortunately does not mean that nobody will. Personally I am fine with the argument that "then they'd better write better XPath queries", so I'm not actually opposed to structuring it like this, I just thought I should mention the potential issue.

Could it make sense to include a field for the thumbprint of a certificate? Purely for validation purposes.

Should the format have a namespace? Full disclosure, I am a product of working exclusively in integration for more than a decade, so it has been pounded into me over the years that every XML format SHOULD have a namespace. However, I do recognize that this is not a common business document type, so the same rules need not apply here.

/Asger