조직 키 파일 서명과 배포

조직 키 파일(~/.evo/org.json)은 조직 사용자를 정하고, 로그인할 인증 서버와 evo-api 주소를 담는다(docs/cli.md “조직 모드”). 파일을 바꾸면 evo가 엉뚱한 서버로 로그인 토큰을 보낼 수 있으므로, 키 파일은 서명해서만 나눠 준다.

• 비밀 값은 없다. 그래서 암호화하지 않는다.
• 서명은 Ed25519로 한다. evo는 빌드에 들어 있는 신뢰 공개 키 목록으로 서명을 확인한다. 공개 키는 비밀이 아니다.
• 서명이 없거나, 모르는 키로 서명했거나, 서명 뒤에 내용을 바꾼 파일은 시작 오류다. 일반 모드로 넘어가지 않는다.
• 서명 개인 키는 서명하는 PC에만 둔다. 저장소·문서·Issue·채팅·메신저에 올리지 않는다.

1. 서명한 키 파일의 형식

{
  "format": "evo-org-key/1",
  "kid": "f9a469b35dc0058f",
  "payload": "<키 파일 JSON의 base64>",
  "sig": "<payload 원본 바이트에 대한 Ed25519 서명, base64>"
}

• payload를 풀면 평소의 키 파일 JSON이다(org, name, auth.url, auth.client_id, auth.scopes, api.url, update.url, dispatch.url, expires). update.url은 선택이며 evo update가 쓸 Nexus 서버 주소다. dispatch.url은 선택이며 조직 모드에서 세션 간 dispatch 서버로 기본 연결할 evo-dispatch 주소다(https://, URL에 안전한 글자만, /mcp로 끝남, 예: "dispatch": {"url": "https://dispatch.acme.example/mcp"}). 버그 신고 공간(/mcp/bugs)·개발 요청 공간(/mcp/dev)은 붙이지 않는다. 키 파일이 서명돼 있으므로 사용자가 이 주소들을 몰래 바꿀 수 없다. update.url·dispatch.url 형식이 틀리면 다른 형식 오류처럼 키 파일 오류(시작 오류)다. auth.scopes는 선택이며, 없으면 openid profile email에 서버가 지원하는 경우 offline_access를 더해 요청한다(docs/cli.md “조직 모드”).
• kid는 서명한 키의 ID다. 공개 키 SHA-256의 앞 8바이트를 hex로 쓴다. evo는 이 값으로 신뢰 목록에서 공개 키를 고른다.

2. 도구 evo-orgkey

관리자용 도구다. evo 릴리스에 들어가지 않는다. 저장소에서 빌드한다.

go build -o evo-orgkey ./cmd/evo-orgkey

명령	하는 일
evo-orgkey genkey -dir <폴더> -name <이름>	새 서명 키 쌍을 만든다. <kid>.key(개인 키, 0600), <kid>.pub, <kid>.txt(이름·kid·공개 키·생성일)를 쓰고 kid와 공개 키를 보여 준다. 개인 키는 출력하지 않는다
evo-orgkey sign -key <개인 키> -in <org.json> -out <서명본>	키 파일에 서명한다
evo-orgkey verify -pub <공개 키,…> -in <서명본>	evo와 같은 방식으로 열어 본다(서명, 필수 항목, 만료, update.url·dispatch.url 형식). dispatch.url이 있으면 함께 보여 준다
evo-orgkey show -in <서명본>	kid와 내용을 보여 준다(검사하지 않음)

3. 조직 키 파일 발급 절차

1. 키 파일 JSON을 만든다(docs/cli.md “조직 모드”의 형식, api.url 필수).

2. 서명한다: evo-orgkey sign -key ~/.evo-signing/<kid>.key -in acme.json -out acme.signed.json

3. 확인한다: evo-orgkey verify -pub <그 키의 공개 키> -in acme.signed.json

4. 배포한다: 설치 저장소(Nexus raw evo-bin)의 org-keys/<조직 이름>.json으로 올린다.

5. 사용자에게 한 줄 설치를 안내한다.

   curl -fsSL <nexus>/repository/evo-bin/install/install.sh | bash -s -- --org-key <조직 이름>

   • --org-key에는 조직 이름(설치 저장소의 org-keys/<이름>.json), URL, 로컬 파일 경로를 줄 수 있다.
   • 설치 스크립트는 evo를 설치하기 전에 키 파일을 받아 서명 형식인지 확인한다.
   • 설치 뒤에는 키 파일을 ~/.evo/org.json에 둔다. 기존 파일이 있으면 org.json.bak.<시각>으로 남긴다.
   • 서명 자체는 evo가 시작할 때 확인한다.
   • 환경변수 EVO_INSTALL_ORG_KEY로 줘도 된다.

이미 evo를 쓰는 사용자는 서명본을 ~/.evo/org.json에 덮어쓰기만 해도 된다.

4. 서명 키를 새로 만들 때 (다른 조직·기관용)

조직이나 기관마다 서명 키를 따로 둘 수 있다. evo 빌드 하나가 여러 공개 키를 신뢰할 수 있다.

1. evo-orgkey genkey -dir ~/.evo-signing -name <누가 쓰는 키인지>
2. 공개 키를 신뢰 목록에 넣는다.
   • 기본 빌드: cmd/evo/personal.go의 orgPublicKeys에 쉼표로 덧붙인다. 커밋 → MR → 릴리스.
   • 기관용 빌드: 빌드할 때 -X main.orgPublicKeys=<공개 키>[,<공개 키>…]로 바꾼다. 기관용 빌드는 그 기관 키만 신뢰하게 할 수 있다.
3. 아래 “서명 키 목록”에 한 줄을 더한다(공개 정보만).
4. 그 키로 서명한 키 파일은 그 공개 키를 넣은 빌드부터 열린다. 릴리스 전에 배포하지 않는다.

키를 잃어버렸거나 유출됐으면 다음 순서로 처리한다.

1. 새 키를 만든다.
2. 신뢰 목록에서 옛 공개 키를 빼고 새 공개 키를 넣어 릴리스한다.
3. 그 키로 서명했던 키 파일을 새 키로 다시 서명해 배포한다.

5. 서명 키 목록

공개 정보만 적는다. 개인 키 값은 어디에도 적지 않는다.

kid	이름(용도)	공개 키	생성일	개인 키 보관	신뢰하는 빌드
f9a469b35dc0058f	evomind (evomind 발급 조직 키 파일)	Couc1FvIvy7QcdJZ+ZIKLyrIhokSwxzCZE67T84VogI=	2026-10-15	서명 담당 개발 PC ~/.evo-signing/f9a469b35dc0058f.key (키 파일 관리 시스템이 생기면 옮긴다)	기본 빌드

6. 개발·테스트 빌드

신뢰 목록이 빈 빌드(-X main.orgPublicKeys=)는 서명을 확인하지 않는다. 서명하지 않은 파일과 서명한 파일을 모두 읽는다. 저장소의 테스트는 이 상태로 돈다. 릴리스 빌드는 항상 신뢰 목록을 가진다.