Statements made by Issuers about supply chain Artifacts must be identifiable, authentic, and non-repudiable;¶
+Statements made by Issuers about supply chain Artifacts must be identifiable, authentic, and non-repudiable¶
such Statements must be registered on a secure append-only Log, so that their provenance and history can be independently and consistently audited;¶
+Such Statements must be registered on a secure append-only Log, so that their provenance and history can be independently and consistently audited¶
Issuers can efficiently prove to any other party the Registration of their Signed Statements; verifying this proof ensures that the Issuer is consistent and non-equivocal when producing Signed Statements.¶
+Issuers can efficiently prove to any other party the Registration of their Signed Statements; verifying this proof ensures that the Issuer is consistent and non-equivocal when producing Signed Statements¶
The first guarantee is achieved by requiring Issuers to sign their Statements and associated metadata using a distributed public key infrastructure. @@ -1344,7 +1344,8 @@
Trust in the Transparency Service itself is supported both by protecting their implementation (using, for instance, replication, trusted hardware, and remote attestation of a system's operational state) and by enabling independent audits of the correctness and consistency of its Registry, thereby holding the organization that operates it accountable. Unlike CT, where independent Auditors are responsible for enforcing the consistency of multiple independent instances of the same global Registry, each Transparency Service is required to guarantee the consistency of its own Registry (for instance, through the use of a consensus algorithm between replicas of the Registry), but assume no consistency between different Transparency Services.¶
Breadth of access is critical so the Transparency Service specified in this architecture cater to two types of audiences:¶
@@ -1360,8 +1361,7 @@Signed Statement Issuers rely on being discoverable and represented as the responsible parties for their registered Signed Statements via Transparency Services in a believable manner. The issuer of a Signed Statement must be authenticated and authorized according to the registration policy of the Transparency Service. Analogously, Transparent Statement Consumers rely on verifiable trustworthiness assertions associated with Transparent Statements and their processing provenance in a believable manner. -If trust can be put into the operations that record Signed Statements in a secure, append-only log via online operations, the same trust can be put into the resulting transparent statement, -issued by the Transparency Services and that can be validated in offline operations.¶
+If trust can be put into the operations that record Signed Statements in a secure, append-only log via online operations, the same trust can be put into the resulting transparent statement, issued by the Transparency Services and that can be validated in offline operations.¶The Transparency Services specified in this architecture can be implemented by various different types of services in various types of languages provided via various variants of API layouts.¶
The interoperability guaranteed by the Transparency Services is enabled via core components (architectural constituents) that come with prescriptive requirements (that are typically hidden away from the user audience via APIs but can be relied upon as non functional requirements). Many of the data elements processed by the core components are based on the Concise Signing and Encryption standard specified in [RFC9052], which is used to produce Signed Statements about Artifacts and to build and maintain a Merkle tree that functions as an append-only Log for corresponding Signed Statements.¶
@@ -1450,9 +1450,7 @@the pre-condition enforced by the Transparency Service before registering a Signed Statement, rendering it a Signed Statement, -based on metadata contained in its COSE Envelope (notably the identity of its Issuer) -and on prior Signed Statements already added to a Registry.¶
+the pre-condition enforced by the Transparency Service before registering a Signed Statement, rendering it a Signed Statement, based on metadata contained in its COSE Envelope (notably the identity of its Issuer) and on prior Signed Statements already added to a Registry.¶
Issuers MAY update their DID Document at any time, for instance to refresh their signing keys or algorithms, but they SHOULD NOT remove or change any of their previous keys unless they intend to revoke all Signed Statements that are registered as Transparent Statements issued with those keys.¶
The Issuer's DID appears in the protected header of Signed Statements' Envelopes, while the version of the key from the DID Document used to sign the Signed Statement is written in the kid header.¶
kid MUST either be an absolute URL,
-or a relative URL. Relative URL MUST be
-relative to an iss value. When relative URL is used,
-iss MUST also be present in the protected header.¶
kid MUST either be an absolute URL, or a relative URL. Relative URL MUST be relative to an iss value. When relative URL is used, iss MUST also be present in the protected header.¶
Resolving kid MUST return an identity document of a registered content type (a set of public keys).
-In the case of kid being an absolute DID URL, the identity document is called a DID Document,
-and is expected ot have content type application/did+json.¶
kid being an absolute DID URL, the identity document is called a DID Document, and is expected ot have content type application/did+json.¶
To dereference a DID URL, it first MUST be resolved. After that the fragment is processed according to the media type.¶
-For example, when resolving did:example:123#key-42,
-first, the identity document for did:example:123 is resolved as content type application/did+json,
-next, the fragment #key-42 is dereferenced to a verification method that contains a publicKeyJwk property.¶
For example, when resolving did:example:123#key-42, first, the identity document for did:example:123 is resolved as content type application/did+json, next, the fragment #key-42 is dereferenced to a verification method that contains a publicKeyJwk property.¶
The content type of publicKeyJwk is expected to be application/jwk+json.¶
The details of both DID resolution and DID dereferencing are out of scope for this document.¶
The iss or kid, might not be DID URLs, however the following interfaces MUST be satisfied in order to ensure
-issuer identity documents, and associated keys are discoverable in a consistent manner.¶
The iss or kid, might not be DID URLs, however the following interfaces MUST be satisfied in order to ensure issuer identity documents, and associated keys are discoverable in a consistent manner.¶
The value of id might be found the iss or sub claims if they are present in the protected header or payload.¶
-resolve = (id: string, accept: content_type = 'application/did+json') => -idDocument (of content type application/did+json). +resolve = (id: string, accept: \ + content_type = 'application/did+json') => + idDocument (of content type application/did+json)¶
For example:¶
@@ -1750,17 +1742,15 @@Editor note, we might wish to eliminate this intermediate identity document content type,
-by treating it as an alterative encoding of application/jwk-set+json or application/cose-key-set.¶
However, there is no media type fragment processing directive -that would enable dereferencing the known key set content types, listed above.¶
+Editor note, we might wish to eliminate this intermediate identity document content type, by treating it as an alterative encoding of application/jwk-set+json or application/cose-key-set.¶
However, there is no media type fragment processing directive that would enable dereferencing the known key set content types, listed above.¶
https://contoso.example/.well-known/openid-configuration.¶
This URL will resolve to a JSON document which contains the property:¶
jwks_uri, for example https://contoso.example/.well-known/jwks.json¶
This URL will resolve to a JSON document of content type application/jwk-set+json,
-which will contain specific keys... for example:¶
This URL will resolve to a JSON document of content type application/jwk-set+json, which will contain specific keys... for example:¶
{
@@ -1783,24 +1772,24 @@
"alg": "RS256",
"kty": "RSA",
"use": "sig",
- "n": "wW9TkSbcn5FV3iUJ-812sqTvwTGCFrDm6vD2U-g23gn6rrBdFZQbf2bgEnSkolph6CanOYTQ1lKVhKjHLd6Q4MDVGidbVBhESxib2YIzJVUS-0oQgizkBEJxyHI4Zl3xX_sdA_yegLUi-Ykt_gaMPSw_vpxe-pBxu-jd14i-jDfwoPJUdF8ZJGS9orCPRiHCYLDgOscC9XibH9rUbTvG8q4bAPx9Ox6malx4OLvU3pXVjew6LG3iBi2YhpCWe6voMvZJYXqC1n5Mk_KOdGcCFtDgu3I56SGSfsF7-tI7qG1ZO8RMuzqH0LkJVirujYzXrnMZ7WgbMPXmHU8i4z04zw",
+ "n": "wW9TkSbcn5FV3iUJ-812sqTvwT...YzXrnMZ7WgbMPXmHU8i4z04zw",
"e": "AQAB",
- "kid": "NTBGNTJEMDc3RUE3RUVEOTM4NDcyOEFDNzEyOTY5NDNGOUQ4OEU5OA",
- "x5t": "NTBGNTJEMDc3RUE3RUVEOTM4NDcyOEFDNzEyOTY5NDNGOUQ4OEU5OA",
+ "kid": "NTBGNTJEMDc3RUE3RUVEOTM4NDcEFDNzEyOTY5NDNGOUQ4OEU5OA",
+ "x5t": "NTBGNTJEMDc3RUE3RUVEOTM4NDcEFDNzEyOTY5NDNGOUQ4OEU5OA",
"x5c": [
- "MIIDCzCCAfOgAwIBAgIJANPng0XRWwsdMA0GCSqGSIb3DQEBBQUAMBwxGjAYBgNVBAMMEWNvbnRvc28uYXV0aDAuY29tMB4XDTE0MDcxMTE2NTQyN1oXDTI4MDMxOTE2NTQyN1owHDEaMBgGA1UEAwwRY29udG9zby5hdXRoMC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBb1ORJtyfkVXeJQn7zXaypO/BMYIWsObq8PZT6DbeCfqusF0VlBt/ZuASdKSiWmHoJqc5hNDWUpWEqMct3pDgwNUaJ1tUGERLGJvZgjMlVRL7ShCCLOQEQnHIcjhmXfFf+x0D/J6AtSL5iS3+Bow9LD++nF76kHG76N3XiL6MN/Cg8lR0XxkkZL2isI9GIcJgsOA6xwL1eJsf2tRtO8byrhsA/H07HqZqXHg4u9TeldWN7DosbeIGLZiGkJZ7q+gy9klheoLWfkyT8o50ZwIW0OC7cjnpIZJ+wXv60juobVk7xEy7OofQuQlWKu6NjNeucxntaBsw9eYdTyLjPTjPAgMBAAGjUDBOMB0GA1UdDgQWBBTLarHdkNa5CzPyiKJU51t8JWn9WTAfBgNVHSMEGDAWgBTLarHdkNa5CzPyiKJU51t8JWn9WTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQA2FOjm+Bpbqk59rQBC0X6ops1wBcXH8clnXfG1G9qeRwLEwSef5HPz4TTh1f2lcf4Pcq2vF0HbVNJFnLVV+PjR9ACkto+v1n84i/U4BBezZyYuX2ZpEbv7hV/PWxg8tcVrtyPaj60UaA/pUA86CfYy+LckY4NRKmD7ZrcCzjxW2hFGNanfm2FEryxXA3RMNf6IiW7tbJ9ZGTEfA/DhVnZgh/e82KVX7EZnkB4MjCQrwj9QsWSMBtBiYp0/vRi9cxDFHlUwnYAUeZdHWTW+Rp2JX7Qwf0YycxgyjkGAUEZc4WpdNiQlwYf5G5epfOtHGiwiJS+u/nSYvqCFt57+g3R+"
+ "MIIDCzCCAfOgAwIBAgIPng0XRWwsd...f5GOGwJS+u/nSYvqCFt57+g3R+"
]
},
{
"alg": "RS256",
"kty": "RSA",
"use": "sig",
- "n": "ylgVZbNR4nlsU_AbU8Zd7ZhVfmYuwq-RB1_YQWHY362pAed-qgSXV1QmKwCukQ2WDsPHWgpPuEf3O_acmJcCiSxhctpBr5WKkji5o50YX2FqC3xymGkYW5NilvFznKaKU45ulBVByrcb3Vt8BqqBAhaD4YywZZKo7mMudcq_M__f0_tB4fHsHHe7ehWobWtzAW7_NRP0_FjB4Kw4PiqJnChPvfbuxTCEUcIYrshRwD6GF4D_oLdeR44dwx4wtEgvPOtkQ5XIGrhQC_sgWcb2jh7YXauVUjuPezP-VkK7Wm9mZRe758q43SWxwT3afo5BLa3_YLWazqcpWRXn9QEDWw",
+ "n": "ylgVZbNR4nlsU_AbU8Zd7ZhVfm...fo5BLa3_YLWazqcpWRXn9QEDWw",
"e": "AQAB",
"kid": "aMIKy_brQk3nLd0PKd9ln",
"x5t": "-xcTyx47q3ddycG7LtE6QCcETbs",
"x5c": [
- "MIIC/TCCAeWgAwIBAgIJH62yWyX7VxxQMA0GCSqGSIb3DQEBCwUAMBwxGjAYBgNVBAMTEWNvbnRvc28uYXV0aDAuY29tMB4XDTIwMDMxMTE5Mjk0N1oXDTMzMTExODE5Mjk0N1owHDEaMBgGA1UEAxMRY29udG9zby5hdXRoMC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKWBVls1HieWxT8BtTxl3tmFV+Zi7Cr5EHX9hBYdjfrakB536qBJdXVCYrAK6RDZYOw8daCk+4R/c79pyYlwKJLGFy2kGvlYqSOLmjnRhfYWoLfHKYaRhbk2KW8XOcpopTjm6UFUHKtxvdW3wGqoECFoPhjLBlkqjuYy51yr8z/9/T+0Hh8ewcd7t6Fahta3MBbv81E/T8WMHgrDg+KomcKE+99u7FMIRRwhiuyFHAPoYXgP+gt15Hjh3DHjC0SC8862RDlcgauFAL+yBZxvaOHthdq5VSO497M/5WQrtab2ZlF7vnyrjdJbHBPdp+jkEtrf9gtZrOpylZFef1AQNbAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPVdE4SPvuhlODV0GOcPE4QZ7xNuMA4GA1UdDwEB/wQEAwIChDANBgkqhkiG9w0BAQsFAAOCAQEAu2nhfiJk/Sp49LEsR1bliuVMP9nycbSz0zdp2ToAy0DZffTd0FKk/wyFtmbb0UFTD2aOg/WZJLDc+3dYjWQ15SSLDRh6LV45OHU8Dkrc2qLjiRdoh2RI+iQFakDn2OgPNgquL+3EEIpbBDA/uVoOYCbkqJNaNM/egN/s2vZ6Iq7O+BprWX/eM25xw8PMi+MU4K2sJpkcDRwoK9Wy8eeSSRIGYnpKO42g/3QI9+BRa5uD+9shG6n7xgzAPGeldUXajCThomwO8vInp6VqY8k3IeLEYoboJj5KMfJgOWUkmaoh6ZBJHnCogvSXI35jbxCxmHAbK+KdTka/Yg2MadFZdA=="
+ "MIIC/TCCAeWgAwIBAgIJH62ygzAPG...xCxmHAbK+KdTka/Yg2MadFZdA=="
]
}
]
@@ -1818,14 +1807,14 @@
5.1.1.2. Dereferencing Public Keys
kid is always present in the protected header.¶
-If iss is also present, kid MUST be a relative URL to iss,
-otherwise kid MUST be an absolute URL that starts with iss.¶
+If iss is also present, kid MUST be a relative URL to iss, otherwise kid MUST be an absolute URL that starts with iss.¶
id = kid if iss is undefined, or iss + # + kid when iss is defined.¶
See also draft-ietf-cose-cwt-claims-in-headers.¶
-dereference = (id: string, accept: content_type = 'application/jwk+json') =>
-publicKeyJwk (of content type application/jwk+json).
+dereference = (id: string, accept: \
+ content_type = 'application/jwk+json') =>
+ publicKeyJwk (of content type application/jwk+json)
¶
For example, when DIDs are used:¶
@@ -1841,8 +1830,8 @@
"kty": "EC",
"crv": "P-384",
"alg": "ES384",
- "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh_Udu2ObLer3cKFBCaAHY1svmbPV69bP3RH",
- "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYHIwGBnN5rd8QWykAprstPdxx4U0uScvDcYd"
+ "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh...er3cKFBCaAHY1svmbPV69bP3RH",
+ "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYH...d8QWykAprstPdxx4U0uScvDcYd"
}
¶
A Transparency Service that accepts to register any valid Signed -Statement offered by anonymous Issuers would only provide -limited value, or no value, to verifiers. As a consequence, some form of -authorization is needed prior to registration of Signed Statements to -ensure completeness of audit. More advanced use case will rely on the -Transparency Service performing additional domain-specific checks before -a Signed Statement is accepted. For example, some Transparency Services -may validate the content of Signed Statements.¶
-We use the term "registration policies" to refer to the checks that are -performed before a Signed Statement is registered given a set of input -values. This baseline specification leaves the implementation of the -registration policy to the provider of the Transparency Services and its -users.¶
-As a minimum we expect that a deployment authenticates the Issuer of the -Signed Statement, which requires some form of trust anchor. As defined -in [RFC6024], "A trust anchor represents an authoritative -entity via a public key and associated data. The public key is used to -verify digital signatures, and the associated data is used to constrain -the types of information for which the trust anchor is authoritative." -The Trust Anchor may be a certificate, a raw public key or other -structure, as appropriate. It can be a non-root certificate when it is a -certificate.¶
-A provider of a Transparency Service is, however, expected to indicate -what registration policy is used in a given deployment and inform its -users about changes to the registration policy.¶
+A Transparency Service that accepts to register any valid Signed Statement offered by anonymous Issuers would only provide limited value, or no value, to verifiers. +As a consequence, some form of authorization is needed prior to registration of Signed Statements to ensure completeness of audit. +More advanced use case will rely on the Transparency Service performing additional domain-specific checks before a Signed Statement is accepted. +For example, some Transparency Services may validate the content of Signed Statements.¶
+We use the term "registration policies" to refer to the checks that are performed before a Signed Statement is registered given a set of input values. +This baseline specification leaves the implementation of the registration policy to the provider of the Transparency Services and its users.¶
+As a minimum we expect that a deployment authenticates the Issuer of the Signed Statement, which requires some form of trust anchor. +As defined in [RFC6024], "A trust anchor represents an authoritative entity via a public key and associated data. +The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." +The Trust Anchor may be a certificate, a raw public key or other structure, as appropriate. It can be a non-root certificate when it is a certificate.¶
+A provider of a Transparency Service is, however, expected to indicate what registration policy is used in a given deployment and inform its users about changes to the registration policy.¶
There are many different candidate verifiable data structures that may be used to implement the Registry, such as chronological Merkle Trees, sparse/indexed Merkle Trees, full blockchains, and many other variants. The Registry is only required to support concise Receipts (i.e., whose size grows at most logarithmically in the number of entries in the Registry) that can be encoded as a COSE Signed Merkle Tree Proof.¶
-It is possible to offer multiple signature algorithms for the COSE signature of receipts' Signed Merkle Tree, or to change the signing algorithm at later points. However, the Merkle Tree algorithm (including its internal hash function) cannot easily be changed without breaking the consistency of the Registry. It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency.¶
+It is possible to offer multiple signature algorithms for the COSE signature of receipts' Signed Merkle Tree, or to change the signing algorithm at later points. +However, the Merkle Tree algorithm (including its internal hash function) cannot easily be changed without breaking the consistency of the Registry. +It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency.¶
{
"type": "urn:ietf:params:scitt:error:badSignatureAlgorithm",
- "detail": "The Statement was signed with an algorithm the server does not support"
+ "detail": "The Statement was signed with an unsupported algorithm"
}
¶