이 규격은 데이터 무결성 [VC-DATA-INTEGRITY] 규격에 부합하는 Ed25519 EdDSA
서명에 대한 증명을 생성하고 검증할 목적으로 암호 스위트를 정의한다. 이 접근법은 미국
국립표준기술연구소가 최신 [FIPS-186-5] 발행물에서 받아들였으며, 암호학을 사용하여
디지털 정보를 보안할 때 미국 연방 정보 처리 요구사항을 충족한다.
이 규격에 기술된 스위트는 입력 문서를 그 정규 형식으로 변환하기 위해 RDF 데이터셋 정규화
알고리즘 [RDF-CANON]이나 JSON Canonicalization Scheme [RFC8785]을 사용한다.
그런 다음 정규 표현을 해싱하고 분리형 서명 알고리즘으로 서명한다.
비규범적이라고 표시된 절뿐 아니라, 이 규격의 모든 저작 지침, 다이어그램, 예시, 참고(note)도 비규범적이다. 이 규격의 그 밖의 모든 것은 규범적이다.
이 문서의 핵심 단어 MAY, MUST, MUST NOT, SHOULD는
여기에 표시된 것처럼 모두 대문자로 나타날 때에만
BCP 14
[RFC2119] [RFC8174]에
설명된 대로 해석된다.
적합 증명(conforming proof)이란 이 규격의 규범적 진술을
준수하는 데이터 모델의 구체적 표현이다. 구체적으로, 이 문서의
2. 데이터 모델 절과 3. 알고리즘 절의
관련된 모든 규범적 진술이 강제되어야 한다.
적합 프로세서(conforming processor)란
적합 증명을 생성하거나 소비하는, 소프트웨어 및/또는 하드웨어로 구현된 모든
알고리즘이다. 적합 프로세서는 적합하지 않은 문서를 소비할 때 오류를 생성해야 한다.
이 문서는 JSON과 JSON-LD 데이터의 예시를 담고 있다. 이 예시 중 일부는 특정 부분을 설명하는
인라인 주석(//)과 예시에 무관한 정보의 생략을 나타내는 생략 부호(...) 같은 기능을
포함하므로 유효하지 않은 JSON이다. 이 예시들을 유효한 JSON이나 JSON-LD로 취급하려면
이러한 부분을 제거해야 한다.
2. 데이터 모델
다음 절들은 이 규격이 암호학적 공개키와 같은 검증 방법과 디지털 서명과 같은 데이터 무결성
증명을 표현하는 데 사용하는 데이터 모델을 개괄한다.
2.1 검증 방법
이 암호 스위트는 에드워즈 곡선 암호 키 자료를 사용하여 생성된 데이터 무결성 증명
[VC-DATA-INTEGRITY]을 검증하는 데 사용된다. 그 키 유형에 대한 인코딩 형식은 이 절에
제공된다. 동등한 암호 키 자료를 낳는 무손실 암호 키 변환 과정이 디지털 서명 처리에
사용될 수 있다.
The cryptosuite property of the proof MUST be eddsa-rdfc-2022 or eddsa-jcs-2022.
The proofValue property of the proof MUST be a detached EdDSA signature
produced according to [RFC8032], encoded using the base-58-btc header and
alphabet as described in the
Multibase section of
Controlled Identifiers v1.0.
eddsa-rdfc-2022 암호 스위트는 입력 문서를 받아 RDF 데이터셋 정규화 알고리즘
[RDF-CANON]을 사용하여 그 문서를 정규화한 다음, 그 출력을 암호학적으로 해싱하고
서명하여 데이터 무결성 증명을 생성한다. 이 절의 알고리즘은 그러한 데이터 무결성 증명의
검증도 포함한다.
RDF 데이터셋 정규화 알고리즘 [RDF-CANON]이 사용될 때, 구현체는 기본적으로
데이터셋 오염을 감지하고,
그러한 감지 시 처리를 중단한다.
이 알고리즘에 필요한 입력은
비보안 데이터 문서(unsecuredDocument)와 변환 옵션(options)이다.
변환 옵션은
암호 스위트에 대한 타입 식별자(type)와 암호 스위트
식별자(cryptosuite)를 포함해야 한다. 변환된 데이터 문서가 출력으로
생성된다. 이 알고리즘이 문자열을 인코딩할 때는 언제나 UTF-8 인코딩을 사용해야 한다.
options.type이 문자열 DataIntegrityProof로 설정되지 않고
options.cryptosuite가 문자열 eddsa-rdfc-2022로 설정되지 않았으면,
PROOF_TRANSFORMATION_ERROR
오류 유형을 전달하는 것이 좋은 오류를 일으켜야 한다.
이 알고리즘에 필요한 입력은 변환된 데이터 문서(transformedDocument)와
정규 증명 구성(canonicalProofConfig)이다. 바이트 열로 표현되는 단일
해시 데이터 값이 출력으로 생성된다.
proofConfigHash를 canonicalProofConfig에 SHA-256(256비트 출력의 SHA-2)
암호 해싱 알고리즘 [RFC6234]을 적용한 결과로 둔다. proofConfigHash는 정확히
32바이트 크기가 된다.
transformedDocumentHash를 transformedDocument에 SHA-256(256비트 출력의
SHA-2) 암호 해싱 알고리즘 [RFC6234]을 적용한 결과로 둔다.
transformedDocumentHash는 정확히 32바이트 크기가 된다.
hashData를 proofConfigHash(위에서 생성한 첫 번째 해시) 뒤에
transformedDocumentHash(위에서 생성한 두 번째 해시)를 이어붙인 결과로 둔다.
hashData를 해시 데이터로 반환한다.
3.2.5 증명 구성(eddsa-rdfc-2022)
다음 알고리즘은 증명 해싱 알고리즘에 입력으로 사용되는
증명 옵션 집합으로부터 증명 구성을 생성하는 방법을 지정한다.
이 알고리즘에 필요한 입력은 문서(unsecuredDocument)와 증명 옵션
(options)이다. 증명 옵션은
암호 스위트에 대한 타입 식별자(type)를 포함해야 하고 암호 스위트
식별자(cryptosuite)를 포함해야 한다. 증명 구성
객체가 출력으로 생성된다.
proofConfig를 options 객체의 복제본으로 둔다.
proofConfig.type이 DataIntegrityProof로 설정되지 않았거나
proofConfig.cryptosuite가 eddsa-rdfc-2022로 설정되지 않았으면,
오류를 일으켜야 하며PROOF_GENERATION_ERROR
오류 유형을 전달하는 것이 좋다.
proofConfig.@context 를
unsecuredDocument.@context로 설정한다.
canonicalProofConfig를 proofConfig에 RDF 데이터셋 정규화 알고리즘
[RDF-CANON]을 적용한 결과로 둔다.
canonicalProofConfig를 반환한다.
3.2.6 증명 직렬화(eddsa-rdfc-2022)
다음 알고리즘은 암호 해시 데이터 집합으로부터 디지털 서명을 직렬화하는 방법을 지정한다. 이
알고리즘은 데이터 무결성 [VC-DATA-INTEGRITY] 규격
4절: 알고리즘에 정의된 알고리즘과 함께 사용되도록 설계되었다. 필요한 입력은
암호 해시 데이터(hashData)와 증명 옵션(options)이다.
증명 옵션은
암호 스위트에 대한 타입 식별자(type)를 포함해야 하고 암호 스위트
식별자(cryptosuite)를 포함할 수 있다. 바이트 열로 표현되는 단일 디지털 증명
값이 출력으로 생성된다.
privateKeyBytes를 options.verificationMethod 값이
식별하는 검증 방법에 연관된 개인키 바이트(또는 그 개인키 바이트의 사용을 가능하게 하는
서명 인터페이스)를 조회한 결과로 둔다.
proofBytes를, privateKeyBytes가 지정하는 개인키를 사용하여 hashData를
서명할 데이터로 하여, Ed25519 변형(순수 EdDSA)을 사용하는 에드워즈 곡선 디지털
서명 알고리즘(EdDSA) [RFC8032]을 적용한 결과로 둔다.
proofBytes는 정확히 64바이트 크기가 된다.
proofBytes를 디지털 증명으로 반환한다.
3.2.7 증명 확인(eddsa-rdfc-2022)
다음 알고리즘은 암호 해시 데이터 집합으로부터 디지털 서명을 검증하는 방법을 지정한다. 이
알고리즘은 데이터 무결성 [VC-DATA-INTEGRITY] 규격
4절: 알고리즘에 정의된 알고리즘과 함께 사용되도록 설계되었다. 필요한 입력은
암호 해시 데이터(hashData), 디지털 서명(proofBytes), 증명 옵션(options)이다.
불리언 값으로 표현되는 검증 결과가 출력으로 생성된다.
verificationResult를, publicKeyBytes가 지정하는 공개키를 사용하여
hashData를 proofBytes에 대해 검증할 데이터로 하여, Ed25519 변형(순수
EdDSA)을 사용하는 에드워즈 곡선 디지털 서명 알고리즘(EdDSA)
[RFC8032]의 검증 알고리즘을 적용한 결과로 둔다.
verificationResult를 검증 결과로 반환한다.
3.3 eddsa-jcs-2022
eddsa-jcs-2022 암호 스위트는 입력 문서를 받아 JSON Canonicalization Scheme
[RFC8785]을 사용하여 그 문서를 정규화한 다음, 그 출력을 암호학적으로 해싱하고
서명하여 데이터 무결성 증명을 생성한다.
구현자는, 증명 집합이나 증명 체인에 포함되지 않을 증명을 생성할 때 2단계가 엄밀히 필요한
것은 아니지만, 생성된 증명이 어디에 사용될지 또는 애플리케이션 계층에서 다른 증명과 어떻게
결합될지 항상 확신할 수 있는 것은 아니라는 점에 유의해야 한다. 일부 구현자는 자신의
소프트웨어가 2단계를 항상 구현하지는 않을 수 있다고 밝혔지만, 항상 2단계를 구현할 것을
강력히 권한다.
이 알고리즘에 필요한 입력은
비보안 데이터 문서(unsecuredDocument)와 변환 옵션(options)이다.
변환 옵션은
암호 스위트에 대한 타입 식별자(type)와 암호 스위트
식별자(cryptosuite)를 포함해야 한다. 변환된 데이터 문서가 출력으로
생성된다. 이 알고리즘이 문자열을 인코딩할 때는 언제나 UTF-8 인코딩을 사용해야 한다.
options.type이 문자열 DataIntegrityProof로 설정되지 않고
options.cryptosuite가 문자열 eddsa-jcs-2022로 설정되지 않았으면,
PROOF_VERIFICATION_ERROR
오류 유형을 전달하는 것이 좋은 오류를 일으켜야 한다.
canonicalDocument를 unsecuredDocument의 JSON 직렬화에 JSON
Canonicalization Scheme [RFC8785]을 적용한 결과로 둔다.
이 알고리즘에 필요한 입력은 변환된 데이터 문서(transformedDocument)와
정규 증명 구성(canonicalProofConfig)이다. 바이트 열로 표현되는 단일
해시 데이터 값이 출력으로 생성된다.
transformedDocumentHash를 transformedDocument에 SHA-256(256비트 출력의
SHA-2) 암호 해싱 알고리즘 [RFC6234]을 적용한 결과로 둔다.
transformedDocumentHash는 정확히 32바이트 크기가 된다.
proofConfigHash를 canonicalProofConfig에 SHA-256(256비트 출력의 SHA-2)
암호 해싱 알고리즘 [RFC6234]을 적용한 결과로 둔다. proofConfigHash는 정확히
32바이트 크기가 된다.
hashData를 proofConfigHash(첫 번째 해시)에 transformedDocumentHash
(두 번째 해시)를 결합한 결과로 둔다.
hashData를 해시 데이터로 반환한다.
3.3.5 증명 구성(eddsa-jcs-2022)
다음 알고리즘은 증명 해싱 알고리즘에 입력으로 사용되는
증명 옵션 집합으로부터 증명 구성을 생성하는 방법을 지정한다.
이 알고리즘에 필요한 입력은 증명 옵션(options)이다. 증명 옵션은
암호 스위트에 대한 타입 식별자(type)를 포함해야 하고 암호 스위트
식별자(cryptosuite)를 포함해야 한다. 증명 구성
객체가 출력으로 생성된다.
proofConfig를 options 객체의 복제본으로 둔다.
proofConfig.type이 DataIntegrityProof로 설정되지 않았거나
proofConfig.cryptosuite가 eddsa-jcs-2022로 설정되지 않았으면,
PROOF_GENERATION_ERROR
오류 유형을 전달하는 것이 좋은 오류를 일으켜야 한다.
canonicalProofConfig를 proofConfig에 JSON Canonicalization Scheme
[RFC8785]을 적용한 결과로 둔다.
canonicalProofConfig를 반환한다.
3.3.6 증명 직렬화(eddsa-jcs-2022)
다음 알고리즘은 암호 해시 데이터 집합으로부터 디지털 서명을 직렬화하는 방법을 지정한다. 이
알고리즘은 데이터 무결성 [VC-DATA-INTEGRITY] 규격
4절: 알고리즘에 정의된 알고리즘과 함께 사용되도록 설계되었다. 필요한 입력은
암호 해시 데이터(hashData)와 증명 옵션(options)이다.
증명 옵션은
암호 스위트에 대한 타입 식별자(type)를 포함해야 하고 암호 스위트
식별자(cryptosuite)를 포함할 수 있다. 바이트 열로 표현되는 단일 디지털 증명
값이 출력으로 생성된다.
privateKeyBytes를 options.verificationMethod 값이
식별하는 검증 방법에 연관된 개인키 바이트(또는 그 개인키 바이트의 사용을 가능하게 하는
서명 인터페이스)를 조회한 결과로 둔다.
proofBytes를, privateKeyBytes가 지정하는 개인키를 사용하여 hashData를
서명할 데이터로 하여, Ed25519 변형(순수 EdDSA)을 사용하는 에드워즈 곡선 디지털
서명 알고리즘(EdDSA) [RFC8032]을 적용한 결과로 둔다.
proofBytes는 정확히 64바이트 크기가 된다.
proofBytes를 디지털 증명으로 반환한다.
3.3.7 증명 확인(eddsa-jcs-2022)
다음 알고리즘은 암호 해시 데이터 집합으로부터 디지털 서명을 검증하는 방법을 지정한다. 이
알고리즘은 데이터 무결성 [VC-DATA-INTEGRITY] 규격
4절: 알고리즘에 정의된 알고리즘과 함께 사용되도록 설계되었다. 필요한 입력은
암호 해시 데이터(hashData), 디지털 서명(proofBytes), 증명 옵션(options)이다.
불리언 값으로 표현되는 검증 결과가 출력으로 생성된다.
verificationResult를, publicKeyBytes가 지정하는 공개키를 사용하여
hashData를 proofBytes에 대해 검증할 데이터로 하여, Ed25519 변형(순수
EdDSA)을 사용하는 에드워즈 곡선 디지털 서명 알고리즘(EdDSA)
[RFC8032]의 검증 알고리즘을 적용한 결과로 둔다.
다음 절은 이 규격을 구현하는 개발자가 안전한 소프트웨어를 만들기 위해
알고 있어야 할 보안 고려사항을 기술한다.
4.1 Ed25519 구현의 보안 속성
이 부분은 비규범적입니다.
Ed25519 서명(edwards25519 곡선을 사용하는 EdDSA 알고리즘)은 키와 서명의
크기가 작고 서명을 생성·검증하는 속도가 빠르다는 두 가지 이유로 널리
채택되어 왔다. Ed25519 서명을 생성하고 검증할 수 있는 라이브러리가 많이
존재한다. [RFC8032]의 발행 이후, Ed25519 서명의 보안 속성은 엄밀하게
증명되었다([Provable_Ed25519] 및 [Taming_EdDSAs] 참조). 그러나 상당수의
라이브러리가 서명 검증 과정에서 입력 유효성 검사를 누락하여 이러한 보안
수준에 도달하지 못한다는 점이 관찰되었다. 이 절에서는 Ed25519 서명으로
달성할 수 있는 보안 수준을 요약하고, 어떤 라이브러리가 그러한 수준을
지원하는지 판단하는 방법을 제시한다.
4.1.1 서명 보안 속성
디지털 서명은 여러 가지 바람직한 암호학적 속성을 가질 수 있으며
[Taming_EdDSAs], 그중에는 다음이 있다:
EUF-CMA (선택 메시지 공격 하에서의 존재적 위조 불가능성(existential unforgeability under
chosen message attacks))은 보통 서명 스킴에 요구되는 최소한의 보안 속성이다. It guarantees that any efficient adversary who has the
public key
of the signer and received an arbitrary number of signatures on
messages of its choice (in an adaptive manner):
,
cannot output a valid signature
for a new message
(except with negligible probability). If the attacker outputs a valid
signature on a new message:
,
it is called an existential
forgery.
SUF-CMA (선택 메시지 공격 하에서의 강한 위조 불가능성(strong unforgeability under chosen
message attacks))은 EUF-CMA보다 더 강한 개념이다. It guarantees
that for any efficient adversary who has the public key
of the signer and
received an arbitrary number of signatures on messages of its choice:
,
it cannot output a new valid signature pair
,
such that
(except with negligible probability). Strong unforgeability implies that an
adversary not only cannot sign new messages, but also cannot find a new signature
on an old message. See [Provable_Ed25519] for a real world attack that would
have been circumvented with SUF-CMA security over EUF-CMA security.
구속 서명(Binding signature) (BS) 어떤 서명
scheme is binding if no efficient signer can output a tuple
,
where both
and
are valid message signature pairs under the public key
and
(except with negligible probability). A binding signature makes it impossible
for the signer to claim later that it has signed a different message; the
signature binds the signer to the message.
강하게 구속하는 서명(Strongly Binding signature) (SBS) 어떤
응용에서는 서명이 메시지에만 구속될 뿐 아니라 공개키에도 구속되기를 요구할 수
있다. We say that a signature scheme is
strongly-binding if any efficient signer cannot output a tuple
,
where
is a valid signature for the public key
and
is a valid signature for the public key
and either
or
,
or both (except with negligible probability). See [Provable_Ed25519] for real
world attacks that would have been circumvented with the SBS property.
BS와 SBS 속성은 부인 방지(non-repudiation)의
한 형태임에 유의한다.
4.1.2 Ed25519 보안 속성 달성
[Taming_EdDSAs]에서 지적하였듯이, Ed25519 라이브러리의 결함은
주로 서명 검증 쪽에서 발생하며, 이때 엣지 케이스가 제대로 검사되지 않는
경우가 있다. [RFC8032] 또는 [FIPS-186-5]를 준수하는, 즉 규정된 모든
유효성 검사를 수행하는 Ed25519 서명 라이브러리는 EUF-CMA에
더하여 SUF-CMA 속성을 가진다.
참고문헌 [Taming_EdDSAs]는 "서명 검증 알고리즘 2"에서
SUF-CMA와 함께 BS 및 SBS 속성을
달성하는데, 여기서는 공개키 A가 여덟 개의 "작은 위수의 점(small order
points)" 중 하나가 아닌지 확인하는 추가 검사를 수행한다. 이러한 추가 검사는
처리 부담을 거의 늘리지 않는다.
참고문헌 [Taming_EdDSAs]는 발행 당시 사용 가능하던 여러 Ed25519
라이브러리를 시험하기 위한 열두 개의 테스트 벡터 집합을 포함하였다. 그 결과
상당수가 엣지 케이스를 놓쳐 SUF-CMA를 달성하지 못했으며(EUF-CMA만
달성), 열여섯 개 라이브러리 중 두 개만이 모든 보안 속성을 달성한 것으로
나타났다. 발행 이후 더 많은 Ed25519 라이브러리가 만들어졌고, 일부 라이브러리는
모든 검증 검사를 포함하도록 갱신되었다. 구현자는 사용 중인 Ed25519 라이브러리를
[Taming_EdDSAs]의 테스트 벡터로 시험할 것을 권장한다.
Ed25519Signature2020은 EdDSA 알고리즘과 Curve25519를 사용하기 위한
암호 스위트의 이전 버전이다. 이는 실제 운영 시스템에서 사용되어 왔으나, 새로운
구현은 대신 eddsa-rdfc-2022를 사용해야 한다.
Ed25519Signature2020은 안정적인 참조를 제공하기 위해 이 규격에 남겨두었다.
A.1 데이터 모델
A.1.1 검증 방법
A.1.1.1 Ed25519VerificationKey2020
이 절에서 기술하는 키 형식은 실제 운영에 배포되어 온 레거시 메커니즘을 문서화하기
위해 제공된다. 2.1.1 Multikey 절에서 기술하는 키 형식이 이 절에서 기술하는
형식을 대체한다. 새로운 응용은 더 새로운 키 형식을 사용할 것을 강력히 권한다.
검증 방법의 publicKeyMultibase 값은
[VC-DATA-INTEGRITY]의
Multibase 절에 정의된 대로
base-58-btc 접두사(z)로 시작해야 한다. 그 뒤에는 Multibase로 인코딩된
Multikey 값이 오며, 이는 Ed25519 공개키에 대한 Multikey 헤더인 2바이트 접두사
0xed01로 시작하여 32바이트의 공개키 데이터가 뒤따르는 이진값으로 구성되어야 하고,
이 전체를 base-58-btc로 인코딩한다. 그 밖의 어떤 인코딩도 허용되어서는 안 된다.
개발자는 개인키의 표현을 실수로 게시하지 않도록 주의하는 것이 좋다. 이 규격의
구현은 publicKeyMultibase 값에 0xed01 이외의 Multikey 헤더 값이 사용되는
경우 오류를 일으킨다.
이 절에서 기술하는 증명 형식은 실제 운영에 배포되어 온 레거시 메커니즘을 문서화하기
위해 제공된다. 2.2.1 DataIntegrityProof 절에서 기술하는
DataIntegrityProof 형식이 이 절에서 기술하는 형식을 대체한다. 새로운 응용은
더 새로운 증명 형식을 사용할 것을 강력히 권한다.
증명의 verificationMethod 속성은 URL이어야 한다.
verificationMethod를 역참조하면 값이 Ed25519VerificationKey2020으로
설정된 type 속성을 담은 객체가 나와야 한다.
Ed25519Signature2020 암호 스위트는 입력 문서를 받아, RDF 데이터셋
정규화 알고리즘 [RDF-CANON]을 사용하여 문서를 정규화한 뒤, 그 출력을
암호학적으로 해싱하고 서명하여 데이터 무결성 증명을 생성한다. 이 절의 알고리즘은
그러한 데이터 무결성 증명의 검증도 포함한다.
이 알고리즘에 필요한 입력은
비보안 데이터 문서(unsecuredDocument)와 변환 옵션(options)이다.
변환 옵션은
암호 스위트에 대한 타입 식별자(type)와 암호 스위트
식별자(cryptosuite)를 포함해야 한다. 변환된 데이터 문서가 출력으로
생성된다. 이 알고리즘이 문자열을 인코딩할 때는 언제나 UTF-8 인코딩을 사용해야 한다.
options.type이 문자열 Ed25519Signature2020으로
설정되어 있지 않으면, 오류를 일으켜야 하며PROOF_TRANSFORMATION_ERROR
오류 유형을 전달하는 것이 좋다.
이 알고리즘에 필요한 입력은 변환된 데이터 문서(transformedDocument)와
증명 구성(proofConfig)이다. 증명 구성은
암호 스위트에 대한 타입 식별자(type)를 포함해야 하고 암호 스위트
식별자(cryptosuite)를 포함할 수 있다. 바이트 열로 표현되는 단일 해시 데이터
값이 출력으로 생성된다.
transformedDocumentHash를 transformedDocument에 SHA-256(256비트 출력의
SHA-2) 암호 해싱 알고리즘 [RFC6234]을 적용한 결과로 둔다.
transformedDocumentHash는 정확히 32바이트 크기가 된다.
proofConfigHash를 canonicalProofConfig에 SHA-256(256비트 출력의 SHA-2)
암호 해싱 알고리즘 [RFC6234]을 적용한 결과로 둔다. proofConfigHash는 정확히
32바이트 크기가 된다.
hashData를 proofConfigHash(첫 번째 해시)에 transformedDocumentHash
(두 번째 해시)를 결합한 결과로 둔다.
hashData를 해시 데이터로 반환한다.
A.2.1.5 증명 구성(Ed25519Signature2020)
다음 알고리즘은 증명 해싱 알고리즘에 입력으로
사용되는 증명 구성을 증명 옵션 집합으로부터 생성하는 방법을 지정한다.
이 알고리즘에 필요한 입력은 증명 옵션(options)이다. 증명 옵션은
암호 스위트에 대한 타입 식별자(type)를 포함해야 하고 암호 스위트
식별자(cryptosuite)를 포함할 수 있다. 증명 구성
객체가 출력으로 생성된다.
proofConfig를 options 객체의 복제본으로 둔다.
proofConfig.type이 Ed25519Signature2020으로 설정되어 있지 않으면,
오류를 일으켜야 하며PROOF_GENERATION_ERROR
오류 유형을 전달하는 것이 좋다.
canonicalProofConfig를 proofConfig에 RDF 데이터셋 정규화 알고리즘
[RDF-CANON]을 적용한 결과로 둔다.
canonicalProofConfig를 반환한다.
A.2.1.6 증명 직렬화(Ed25519Signature2020)
다음 알고리즘은 암호 해시 데이터 집합으로부터 디지털 서명을 직렬화하는 방법을 지정한다. 이
알고리즘은 데이터 무결성 [VC-DATA-INTEGRITY] 규격
4절: 알고리즘에 정의된 알고리즘과 함께 사용되도록 설계되었다. 필요한 입력은
암호 해시 데이터(hashData)와 증명 옵션(options)이다.
증명 옵션은
암호 스위트에 대한 타입 식별자(type)를 포함해야 하고 암호 스위트
식별자(cryptosuite)를 포함할 수 있다. 바이트 열로 표현되는 단일 디지털 증명
값이 출력으로 생성된다.
privateKeyBytes를 options.verificationMethod 값이
식별하는 검증 방법에 연관된 개인키 바이트(또는 그 개인키 바이트의 사용을 가능하게 하는
서명 인터페이스)를 조회한 결과로 둔다.
proofBytes를, privateKeyBytes가 지정하는 개인키를 사용하여 hashData를
서명할 데이터로 하여, Ed25519 변형(순수 EdDSA)을 사용하는 에드워즈 곡선 디지털
서명 알고리즘(EdDSA) [RFC8032]을 적용한 결과로 둔다.
proofBytes는 정확히 64바이트 크기가 된다.
proofBytes를 디지털 증명으로 반환한다.
A.2.1.7 증명 확인(Ed25519Signature2020)
다음 알고리즘은 암호 해시 데이터 집합으로부터 디지털 서명을 검증하는 방법을 지정한다. 이
알고리즘은 데이터 무결성 [VC-DATA-INTEGRITY] 규격
4절: 알고리즘에 정의된 알고리즘과 함께 사용되도록 설계되었다. 필요한 입력은
암호 해시 데이터(hashData), 디지털 서명(proofBytes), 증명 옵션(options)이다.
불리언 값으로 표현되는 검증 결과가 출력으로 생성된다.
verificationResult를, publicKeyBytes가 지정하는 공개키를 사용하여
hashData를 proofBytes에 대해 검증할 데이터로 하여, Ed25519 변형(순수
EdDSA)을 사용하는 에드워즈 곡선 디지털 서명 알고리즘(EdDSA)
[RFC8032]의 검증 알고리즘을 적용한 결과로 둔다.
verificationResult를 검증 결과로 반환한다.
B. 테스트 벡터
이 부분은 비규범적입니다.
B.1 표현: eddsa-rdfc-2022
서명자는 서명에 사용할 개인키와 검증에 사용할 수 있도록 공개할 공개키로 이루어진
개인키/공개키 쌍을 생성해야 한다. 공개키의 표현과 개인키의 표현을 아래에 나타낸다.
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"credentialSubject":{"alumniOf":"The School of Examples","id":"did:example:abcdefgh"},"description":"A minimum viable example of an Alumni Credential.","id":"urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33","issuer":"https://vc.example/issuers/5678","name":"Alumni Credential","type":["VerifiableCredential","AlumniCredential"],"validFrom":"2023-01-01T00:00:00Z"}
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
"type": [
"VerifiableCredential",
"AlumniCredential"
],
"name": "Alumni Credential",
"description": "A minimum viable example of an Alumni Credential.",
"issuer": "https://vc.example/issuers/5678",
"validFrom": "2023-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:abcdefgh",
"alumniOf": "The School of Examples"
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
"proofPurpose": "assertionMethod",
"proofValue": "z57Mm1vboMtZiCyJ4aReZsv8co4Re64Y8GEjL1ZARzMbXZgkARFLqFs1P345NpPGG2hgCrS4nNdvJhpwnrNyG3kEF"
}
}
B.5 증명 집합과 증명 체인
증명 집합과 증명 체인은 [VC-DATA-INTEGRITY]에 정의되어 있다. 여기서는
eddsa-rdfc-2022 암호 스위트로 증명 집합과 증명 체인을 생성하는 과정을
보여주는 테스트 벡터를 제공한다. 증명 집합과 증명 체인의 생성에는 여러 서명자가
관여할 수 있으므로 여러 개의 공개키/개인키 쌍이 필요하다. 이를 아래에 나타낸다.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
"type": [
"VerifiableCredential",
"AlumniCredential"
],
"name": "Alumni Credential",
"description": "A minimum viable example of an Alumni Credential.",
"issuer": "https://vc.example/issuers/5678",
"validFrom": "2023-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:abcdefgh",
"alumniOf": "The School of Examples"
},
"proof": {
"type": "DataIntegrityProof",
"id": "urn:uuid:26329423-bec9-4b2e-88cb-a7c7d9dc4544",
"cryptosuite": "eddsa-rdfc-2022",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "did:key:z6MktgKTsu1QhX6QPbyqG6geXdw6FQCZBPq7uQpieWbiQiG7#z6MktgKTsu1QhX6QPbyqG6geXdw6FQCZBPq7uQpieWbiQiG7",
"proofPurpose": "assertionMethod",
"proofValue": "z66vWyqwAghu52WbpRkCwFRTu6Msn92ArtjpJ3gGMSVoU5RADwBfszoDt1QWY8owqLPz4nTj7hAwV7xFti1p93zdr"
}
}
[VC-DATA-INTEGRITY]의
4.4절: 증명 집합/체인 추가에 대한 options 입력을 아래에 나타낸다.
여기서는 체인이 아니라 증명 집합을 구성하고 있으므로 previousProof 속성을
포함하지 않는다는 점에 유의한다. 또한 서명에는 keyPair2를 사용한다.
이 테스트 벡터 모음은 증명 체인의 구성을 보여준다. 증명 집합을 담은 문서, 즉 앞의
예시에서 시작하여, 기존 증명에 대한 의존성을 갖는 새 증명을 크리덴셜에 추가한다. 이
예시는 previousProofs 속성이 배열인 경우도 보여준다. 이 예시는
keyPair3을 사용하며 시작 문서는 아래와 같다.
[VC-DATA-INTEGRITY]의
4.4절: 증명 집합/체인 추가 알고리즘에 따라, 배열 변수 allProofs를
만들고 시작 문서의 증명들을 여기에 추가한다. options에 previousProof 속성이
있으므로, 4.4절: 증명 집합/체인
추가의 4단계에 따라 matchingProofs 변수를 계산하고,
unsecuredDocument.proof를 matchingProofs와 같게 설정한다. 이로써
아래에 나타낸 문서가 만들어진다.
[VC-DATA-INTEGRITY]의
4.4절: 증명 집합/체인 추가 알고리즘에 따라, 배열 변수 allProofs를
만들고 시작 문서의 증명들을 여기에 추가한다. options에 previousProof
속성이 있으므로, 4.4절: 증명 집합/체인
추가의 4단계에 따라 matchingProofs 변수를 계산하고,
unsecuredDocument.proof를 matchingProofs와 같게 설정한다. 이로써
아래에 나타낸 문서가 만들어진다.
Added support for JSON Canonicalization Scheme in addition to RDF Dataset
Canonicalization.
Added test vectors for rdfc and jcs cryptosuites.
Deprecated and moved Ed25519Signature2020 to appendix.
Add Security Considerations for proper implementation of EdDSA.
Move normative definition of Multikey to the Data Integrity specification.
Add RDF-CANON mitigation for Dataset poisoning.
Revise cryptographic suite names and align with other cryptosuites.
Add secretKeyMultibase definition.
D. Acknowledgements
이 부분은 비규범적입니다.
Work on this specification has been supported by the Rebooting the Web of Trust
community facilitated by Christopher Allen, Shannon Appelcline, Kiara Robles,
Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny, Drummond Reed, Joe
Andrieu, Heather Vescent, Kim Hamilton Duffy, Samantha Chase, Andrew Hughes,
Erica Connell, Shigeya Suzuki, Zaïda Rivai, Will Abramson, and Eric Schuh. The
participants in the Internet Identity Workshop, facilitated by Phil Windley,
Kaliya Young, Doc Searls, and Heidi Nobantu Saul, also supported the refinement
of this work through numerous working sessions designed to educate about, debate
on, and improve this specification.
The Working Group also thanks our Working Group Chair Brent Zundel, and ex-chair
Kristina Yasuda, as well as our W3C Staff Contact, Ivan Herman, for their expert
management and steady guidance of the group through the W3C standardization
cycle. We also thank the Chairs of the W3C Credentials Community Group,
Christopher Allen, Joe Andrieu, Kim Hamilton Duffy, Heather Vescent, Wayne
Chang, Mike Prorock, Harrison Tang, Kimberly Wilson Linson, and Will Abramson,
who oversaw the incubation of this work.
Portions of the work on this specification have been funded by the United States
Department of Homeland Security's Science and Technology Directorate under
contracts 70RSAT20T00000029, 70RSAT21T00000016, 70RSAT23T00000005,
70RSAT20T00000010/P00001, 70RSAT20T00000029, 70RSAT21T00000016/P00001,
70RSAT23T00000005, 70RSAT23C00000030, 70RSAT23R00000006, 70RSAT24T00000011, and
the National Science Foundation through NSF 22-572. The content of this
specification does not necessarily reflect the position or the policy of the
U.S. Government and no official endorsement should be inferred.
The Working Group would like to thank the following individuals for reviewing
and providing feedback on and implementations of the specification
(in alphabetical order by last name):
Greg Bernstein,
Simon Bihel,
Sebastian Crane,
Stas Dmytryshyn,
Tashi D. Gyeltshen,
Ivan Herman,
Andrew Jones,
Filip Kolarik,
Helge Krueger,
Dominik Kuziński,
Charles E. Lehner,
Dave Longley,
Tyler Minard,
Bryan Newbold,
Marty Reed,
Brian Richter,
Eugeniu Rusu,
Markus Sabadello,
Pritam Singh,
Patrick St. Louis,
Manu Sporny,
Orie Steele,
Ted Thibodeau Jr.,
Benjamin Young, and
Dmitri Zagidulin.