Skip to Content.
Sympa Menu

metadata-support - RE: [Metadata-Support] MDQ format options?

Subject: InCommon metadata support

List archive

RE: [Metadata-Support] MDQ format options?


Chronological Thread 
  • From: "Cantor, Scott" <>
  • To: "" <>
  • Subject: RE: [Metadata-Support] MDQ format options?
  • Date: Thu, 8 Dec 2016 15:32:38 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=osu.edu; incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=bestguesspass action=none header.from=osu.edu;
  • Ironport-phdr: 9a23:Q52ajRz09r1GbGzXCy+O+j09IxM/srCxBDY+r6Qd2usfIJqq85mqBkHD//Il1AaPBtSAra8YwLGI+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1Ov71GonPhMiryuy+4ZPebgFGiTanYb5/Ixq6oAvQu8ILnYZsN6E9xwfTrHBVYepW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH0169bwtRbfVwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXzmp8qFmQwLqhigaLT406GHZhNJtgqJHrhyvpBJ/zIzVYI6JO/RxcbjQfc8BSmdFQspdSzBND4G6YoASD+QBJ+FYr4zlqlcAsxaxHw+sBP/oyj9SnnP9wLA03PgmEQHawAwsEc8FvXPIo9rvMqcSTee1zLPSwTnddP5W3iz96JXSfh8/vP6MQKt9fMzMwkcsDwPIlkicpZDqMj+P2ekAsXKX4uV+We61j2MqpRl9riWxysovkIXFm40Yx1He+Sh9z4s5P8C0RU97bNK8HptfqSKXO5dzT84nTWxnpDs1yrMDtJO1fiUG1oooyhvQZvOZc4WF4BfuW/uKLjtmnn1ofq+0iQyo/ki60OL8U9G50FZUoSpBldnBrmgD2gDU5MSbRPZx51qs1jSR2wzK7eFLOl47mbDcK5483r4/jZ0TsVnFHiDrgkn2lLWWdkI4+ue29+vnfrTmppiaN4NujQH+L7gumsi4AeQ/MQgCRXSU+eO51LH7/E35RqtFjuEun6XErJzXKt4Xq6G7DgNP3Ysv9QyzAjOo3dgAmHkINlNFeBaJj4jzPFHOJej1AuuljFSqjDdrwOrGMqf/DpjWKXjDi6rhcaxj5EFB1Qo/1cpf6I5MCrEdPPLzXVf8tN3eDhAlNAy0xuPnCNJ71o8EXmKPGKCZPLrXsVCW+uIgOfSDa5UJuDnnMvQl/OPujWchmV8aZ6mpwYAaaHS5HvR9P0WZemTgjs0AEWcMogoxUvbqiFucXj5PeXq+Rbwz6SwmCNHuMYCWDIWgnLWN1TuyW4ZLfnhBEEykEHHjcICBXPFKbzidaIc1lzEYXLSoV4Zkzgy2rAjg15JmKOHT/ygfs9TkztcjtMPJkhRnvxd9CdiaySXFdGpzgn9CD2s91aZjplY7kH+EyrU+jvBFQ48Ar8hVWxs3YMaPh9dxDMr/D1rM
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99
> I've never seen such a thing. Can you point me to an example or a
> further explanation?

Comodo's recent SHA1/2 migration is an example, they had an additional CA in
the mix that was the same intermediate key but was signed by their old SHA-1
root, so that root stores that only contained the old SHA-1 CA would trust
the new SHA-2 certs.

But now that I write it, I'm not sure it works if you don't control both
hierarchies, so I'm probably wrong, at least with most PKIX code. The actual
EE cert is going to have a single issuer, and Comodo wouldn't let you sign a
CA cert to issue others with, so the issuer at the bottom is going to be
Comodo and there will only be one path up from there.

Oh well...

Separate URL would still work.

-- Scott


Archive powered by MHonArc 2.6.19.

Top of Page