Posted at: 2018-05-20 02:57:56  Category: memo

記事の目的

マンダリンオリエンタル東京に宿泊してきました。
その時の記録を残したいと思います。

ホテルについて

マンダリンオリエンタル東京は、東京日本橋の日本橋三井タワー30F~38Fにあるホテルです。
日本橋三井タワーは、東京メトロの三越前駅A8出口に直結しており、ビル周辺には三越本店や
COREDO室町などがあります。



ビル一階には、千疋屋の本店が入っています。

#千疋屋

moratoriさん(@moratori_)がシェアした投稿 -


正面から入り奥に進み怪しげな通路を抜けると、ホテルフロントに向かうエレベーターがあります。
荷物を持って歩いていたらすぐにスタッフの方がエレベーターまで案内してくれました。
ホテルフロントレセプションは、38Fにあり30F~37Fが客室となっています。

宿泊の内容


部屋のタイプは、スイートでない普通の客室で4種類ある様ですが、
その中の、デラックス プレミア ルームという50m^2の部屋に宿泊しました。
普通の客室の中では2番目に安いお部屋です。

部屋の雰囲気としてはこんな感じで、和モダンっぽい様子です。

moratoriさん(@moratori_)がシェアした投稿 -



部屋に到着するなりすぐに季節のフルーツが出てきました。

#柿 #果物

moratoriさん(@moratori_)がシェアした投稿 -



部屋からの景色です。
スカイツリーが正面に見え、天気が良いと遠くに筑波山が見えるとの事、ベルマンの方が言っていました。
写真にはうまく映りませんでした。

moratoriさん(@moratori_)がシェアした投稿 -



まとめ

とてもいいホテルだなと思いました。
スタッフの方も遠くにいても態々会釈をしてくれたり丁寧で、
さすが世界一のホテルと称されただけはあると思いました。
とても頻繁に宿泊することのできるところではないですが、また機会があれば行きたいと思います。
Posted at: 2018-04-06 04:42:35  Category: memo


CRL Distribution PointsからDER形式のCRLをダウンロードして、
CRLの中身をopensslで確認してみます。CRL Distribution Pointsとは、下記の記載のことです。
・・・省略・・・

X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/sha2-ev-server-g2.crl
Full Name:
URI:http://crl4.digicert.com/sha2-ev-server-g2.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.2.1
CPS: https://www.digicert.com/CPS
Policy: 2.23.140.1.1
・・・省略・・・
あなたとCRL、今すぐダウンロード。
$ wget http://crl3.digicert.com/sha2-ev-server-g2.crl
中身をみてみます。
$ openssl crl -inform DER -in sha2-ev-server-g2.crl -text -noout

Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
Last Update: Apr 4 17:04:34 2018 GMT
Next Update: Apr 11 17:00:00 2018 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:3D:D3:50:A5:D6:A0:AD:EE:F3:4A:60:0A:65:D3:21:D4:F8:F8:D6:0F

X509v3 CRL Number:
297
X509v3 Issuing Distrubution Point: critical
Full Name:
URI:http://crl3.digicert.com/sha2-ev-server-g2.crl

Revoked Certificates:
Serial Number: 0E6661714B51D961E7CC9F98898D3B09
Revocation Date: Jun 13 19:44:41 2017 GMT
Serial Number: 0C739DEE06FCE885BCB5470C18F593B2
Revocation Date: Jun 14 13:54:24 2017 GMT
Serial Number: 0AE90F05DED223B48FBD2978F54F2229
Revocation Date: Jun 15 18:00:13 2017 GMT
・・・省略(失効された証明書のシリアル番号がいっぱい)・・・
Signature Algorithm: sha256WithRSAEncryption
28:1c:4a:ad:de:4e:24:cb:14:3a:33:52:6d:19:12:31:66:09:
64:6c:07:08:10:a8:3e:43:46:85:52:0d:c5:e0:26:0a:3e:a0:
ca:f6:bc:3f:1b:eb:22:99:b0:30:d1:54:64:e8:69:cf:12:98:
9c:b4:60:f9:24:45:d9:74:d5:f9:52:9f:7c:cc:e9:f0:de:89:
55:0f:6e:54:6a:16:49:05:e0:35:7d:36:39:74:3b:bb:3d:37:
a8:a8:f0:de:13:d3:dc:3c:a8:09:df:a6:34:c5:a6:fb:e2:76:
d9:1a:ea:a8:87:50:36:ee:3f:8f:84:68:21:9a:79:78:fd:4d:
f6:b9:ae:16:93:87:bf:12:d1:9d:5f:81:ed:94:25:38:89:e6:
26:1f:aa:b1:70:8e:4c:3c:b8:ee:1d:49:ed:76:6b:74:78:b0:
2d:d2:83:54:e1:fc:0f:1f:74:03:55:57:b3:5c:be:4b:88:6e:
91:22:71:84:cc:39:af:4d:f8:a6:29:b3:de:8e:61:57:b5:35:
12:6e:9f:a3:66:ea:3a:33:48:7e:97:37:5d:1c:ac:58:d6:06:
e9:c8:a8:ee:b4:34:44:4c:4e:52:85:af:00:56:89:a2:ae:d6:
c6:e2:1b:6b:2a:aa:32:57:a1:b2:4c:89:ae:7f:2e:8f:30:69:
21:23:ef:8c
五千件程度のEV証明書が失効されてました。

標準出力せずに、PEMに変換する方法は次のコマンドで
openssl crl -inform DER -in sha2-ev-server-g2.crl -outform PEM

Posted at: 2018-03-07 08:52:59  Category: memo


自社が提供しているサービスについて、サービスの仕様に穴がなく、
想定しない様な使われ方をしない事を検証したいです。

一般的に、どの様な方法で自社のサービスの妥当性は検証されているんだろう。


開発当初のサービス(システム)は要求仕様が比較的小さい場合が多い気がします。
サービスリリース前であれば比較的時間を掛けてサービスの仕様を検討することが
可能な場合が多い気がします。なので、仕様上の不具合は少ないと思います。

リリース後、機能追加が繰り返される度に仕様は膨大になります。
仕様上の不具合が混入する可能性が増します。

"それは仕様です"と言えるレベルのものとか、リスクを取ってお詫び(返金)で済むもの
であればいいと思いますが、サービスの根幹に関わる類のものとか、
お詫びで済まないもの(人命が掛かってるとか)だとアウトだと思います。

サービスの仕様を検討する段階で、不具合を除去して洗練させていく過程を
極力人の力に頼らないで、機械で網羅的に検証する方法って確立されていたりするんですかね。
(要求工学とかの分野なんでしょうか)

この辺、形式検証系のシステムとかととても相性がよさそうだなーって気がしました。

いろいろ調べてみたいなーとあ思います。
Posted at: 2016-10-24 07:51:22  Category: memo

一階述語論理の導出に関するめも







Posted at: 2016-09-10 09:45:46  Category: memo

memo